Hide ToString specializations behind a private trait

[SkiFire13]

Normally we use private traits for specializing impls but ToString's were public and the original PR #32586 doesn't seem to have a reason for this. This PR moves those impls to a hidden perma-unstable SpecToString trait (I would have made it private if proc_macro didn't have to specialize it too) and delegates to it, leaving only the impl<T: fmt::Display + ?Sized> ToStringSpec for T as public.

[rust-highfive]

r? @kennytm

(rust-highfive has picked a reviewer for you, use r? to override)

[kennytm]

but isn't proc_macro specializing ToString an example why the default fn should be kept public 🤔

[SkiFire13]

proc_macro will still use the specialized version, just not publicly

[kennytm]

actually #32586 (comment) questioned the rationale of making ToString publicly specializable, the response was

Very good question. We talked about this some in a recent libs meeting -- ultimately, we're going to want a conventions RFC here, I think. But it's hard to get there without some experimentation first.

what i interpret is that there's no preference in wanting either way. afaik no conventions RFC exists yet. has any experimentation been done?

IMO creating a private-but-actually-public SpecToString trait to hide away the specialization possibility does not provide much benefits over keeping ToString specializable, as long as #31844min_specialization is still unstable.

[SkiFire13]

what i interpret is that there's no preference in wanting either way. afaik no conventions RFC exists yet

While not technically being an RFC, the std-dev-guide specifies that specialization should use private traits https://std-dev-guide.rust-lang.org/code-considerations/using-unstable-lang/specialization.html

IMO creating a private-but-actually-public SpecToString trait to hide away the specialization possibility does not provide much benefits over keeping ToString specializable, as long as #31844 min_specialization is still unstable.

I agree with that, however at least the change makes it consistent with how specialization is handled in the rest of the stdlib.

[the8472]

IIRC the reason for hiding specializations had something to do with the specialized methods being nameable through fully qualified function calls, e.g. <SpecializedImpl as Trait>::specialized_function. The part that I don't recall is what the negative impact of that was. 😅

[bors]

☔ The latest upstream changes (presumably #92598) made this pull request unmergeable. Please resolve the merge conflicts.