library stabilization: allow inherent methods on primitive types

[aturon]

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:

• Most important, people are tempted to use these traits for generic programming (taking Str-bounded types, and/or implementing Str on their own types), which is very much not the intention.
• It clutters the exports of several modules in core and std.
• It's harder for newcomers to understand what's going on, since it's not clear whether the type or the trait is important.

If we could allow inherent impl blocks for primitive types, we could avoid stabilizing these extension traits.

[reem]

Why should people not write functions which accept Str, for instance? I've found this makes for much more ergonomic APIs in many cases. I know it increases the size of the binary, but in many cases that doesn't matter as much as ease of use.

[huonw]

(I think StrSlice is a better example of an extension trait; Str is actually somewhat designed with generic code in mind, while StrSlice is, atm, just to put methods on &str.)

[alexcrichton]

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!

[SiegeLord]

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.

[aturon]

cc @japaric

[japaric]

If we could allow inherent impl blocks for primitive types, we could avoid stabilizing these extension traits.

@aturon Could you be more specific about which traits would get replaced with inherent impls? Int? Float? (I have a rough idea of how to do this. I don't know if it would ulimately work, and it involves one lang item per primitive impl)

[reem]

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."

[huonw]

We can "stability-seal" traits by having #[unstable] non-default methods on them, which means they cannot be implemented in stable code.

[aturon]

@japaric Also StrExt, CharExt, PtrExt.

[aturon]

@japaric oh and SliceExt.

This change would make the documentation much friendlier, would ease the back-compat story (as @reem points out), and help clarify the story about the numeric traits (by relegating all generics to external libraries for the time being).