r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Apologies if there was previously a ruling on this, but waaaayyy back in the day we considered an allocation-free coercion from &'static str to a zero-capacity String. This would've relied upon String not being StableAddress and instead allocating in DerefMut. There were a lot of challenges with this idea, but a lot of value as well.

Providing const DerefMut for String would permanently put a nail in this coffin, so I think there should be a clear "no-go" decision on this idea from lang and libs before stabilizing such an impl.

cc @rust-lang/libs ^^

Oh, I was not aware of that. Thank you for the context, @cramertj.

But Vec<T> already has a const DerefMut on track to stabilise, and it faces an identical concern. If that trade-off was accepted for Vec, I would argue it was implicitly accepted for String too, since String is essentially a specialised Vec<u8>.

Is there a distinction between the two that I am missing?

I don't think Vec should be taken as prior art, my guess would be that the same question was just overlooked.

FWIW I agree with the points in #155816 that this PR goes too far -- only under truly exceptional circumstances should we do anything with const traits in alloc or std. All the core stuff we need for actual experimentation is in core, after all.