library stabilization: allow inherent methods on primitive types #16862
Comments
|
Why should people not write functions which accept |
|
(I think |
|
cc #11409 This was initially attempted to also improve rustdoc output. The rustdoc issue has since been fixed as it was seen as too big of a hammer to add inherent methods to primitive types for that problem, but it's certainly another beneficiary! |
|
Using/abusing traits to add inherent methods to types is necessary in more cases than just primitive types (e.g. imagine if rust-lang/rfcs#155 is accepted), so from my POV the primitive types are a red-herring and what is necessary here is to prevent users from deriving those traits (which can be done via private super-traits). The second two points, in particular, are issues with all uses of such traits, and in some ways, of all uses of traits in general. |
|
cc @japaric |
@aturon Could you be more specific about which traits would get replaced with inherent impls? |
|
This is also a backwards-compatability hazard since changing the signature of any trait method is a backwards incompatible change, even if that trait is meant to be "sealed." |
|
We can "stability-seal" traits by having |
|
@japaric Also |
- Allow inherent implementations on `char`, `str`, `[T]`, `*const T`, `*mut T` and all the numeric primitives.
- copy `unicode::char::CharExt` methods into `impl char`
- remove `unicode::char::CharExt`, its re-export `std::char::CharExt` and `CharExt` from the prelude
- copy `collections::str::StrExt` methods into `impl str`
- remove `collections::str::StrExt` its re-export `std::str::StrExt`, and `StrExt` from the prelude
- copy `collections::slice::SliceExt` methods into `impl<T> [T]`
- remove `collections::slice::SliceExt` its re-export `std::slice::SliceExt`, and `SliceExt` from the prelude
- copy `core::ptr::PtrExt` methods into `impl<T> *const T`
- remove `core::ptr::PtrExt` its re-export `std::ptr::PtrExt`, and `PtrExt` from the prelude
- copy `core::ptr::PtrExt` and `core::ptr::MutPtrExt` methods into `impl<T> *mut T`
- remove `core::ptr::MutPtrExt` its re-export `std::ptr::MutPtrExt`, and `MutPtrExt` from the prelude
- copy `core::num::Int` and `core::num::SignedInt` methods into `impl i{8,16,32,64,size}`
- copy `core::num::Int` and `core::num::UnsignedInt` methods into `impl u{8,16,32,64,size}`
- remove `core::num::UnsignedInt` and its re-export `std::num::UnsignedInt`
- move `collections` tests into its own crate: `collectionstest`
- copy `core::num::Float` methods into `impl f{32,64}`
Because this PR removes several traits, this is a [breaking-change], however functionality remains unchanged and breakage due to unresolved imports should be minimal. If you encounter an error due to an unresolved import, simply remove the import:
``` diff
fn main() {
- use std::num::UnsignedInt; //~ error: unresolved import `std::num::UnsignedInt`.
-
println!("{}", 8_usize.is_power_of_two());
}
```
---
cc #16862
[preview docs](http://japaric.github.io/inherent/std/index.html)
[unicode::char](http://japaric.github.io/inherent/unicode/primitive.char.html)
[collections::str](http://japaric.github.io/inherent/collections/primitive.str.html)
[std::f32](http://japaric.github.io/inherent/std/primitive.f32.html)
|
Can this be closed? Seems like #23104 addressed this. |
|
Indeed! |
internal: remove redundant clone()s
Currently, the only way we can provide methods for primitive types like slices it through public extension traits (like
Str). This approach has a few downsides:Str-bounded types, and/or implementingStron their own types), which is very much not the intention.If we could allow inherent
implblocks for primitive types, we could avoid stabilizing these extension traits.The text was updated successfully, but these errors were encountered: