specialize ToString for str

[seanmonstar]

If there was some conditional compiling we could do, such that this impl only exists in nightly, and is turned off in beta/stable, I think that'd be an improvement here, as we could test specialization out without affecting stable builds.

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[sfackler]

Travis is unhappy: https://travis-ci.org/rust-lang/rust/builds/119328869

[alexcrichton]

Thanks for the PR! @rust-lang/libs actually just started talking about whether we want to use specialization in the standard library. The conclusion so far is that we don't want want to make any strong commitments in terms of enabling new functionality just yet (as specialization isn't 100% on the path to stabilization yet), but small perf improvements like this seem reasonable for the standard library to do.

I'm personally in favor of a change like this to test out specialization, but if we hit ICEs here and there we should be ready to revert relatively quickly.

[SimonSapin]

Does #[unstable] have any effect on impl?

[sfackler]

Nope - it should probably be change to stable.

[seanmonstar]

Fixed stability attribute.

[alexcrichton]

The libs team discussed this during triage today and the decision was to merge! This does not expand the standard library's API surface area, provides a clear performance benefit, and it's very difficult to rely on specialization where code would break if we removed it for whatever reason. @aturon was also "very confident" that this would not ICE :)

@bors: r+ fc8cf9c

Thanks for the PR @seanmonstar!

[aturon]

@alexcrichton ... I did suggest a crater run ;-)

[alexcrichton]

Oh oops I may have misinterpreted in that case. I'll schedule a crater run.

@bors: r-

[alexcrichton]

Crater says zero regressions, yay!

@bors: r+ fc8cf9c

[bors]

⌛️ Testing commit fc8cf9c with merge 3b342fa...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-64-x-armhf, auto-linux-64-x-armsf, auto-linux-64-x-freebsd, auto-linux-64-x-netbsd, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt, auto-win-msvc-64-opt-mir, auto-win-msvc-64-opt-rustbuild

[bluss]

Cool! 💀 to the ".to_string()" is slow memes!

More procedural question: This type of change makes the blanket ToString impl downstream specializable. Do we want this? What do we need to think of when deciding whether to allow that with a default or not?

[aturon]

@bluss 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.

[petrochenkov]

@bluss

This type of change makes the blanket ToString impl downstream specializable. Do we want this? What do we need to think of when deciding whether to allow that with a default or not?

RFC 1422 gives a general way to limit various permissions. The RFC talks only about permission to access (pub(path)), but the same mechanism can be also applied to permissions to specialize , permissions to implement and even permissions to mutate maybe.

In this particular case something like default(crate) could be used to limit the permission to specialize this method to the local crate until the decision to make it specializabe by third parties is achieved.

[bluss]

@petrochenkov You could take the approach in PR #32699 instead if specialization is not open to the outside (use an intermediate internal trait).