Tracking issue for DST coercions (coerce_unsized, unsize) stabilization

[aturon]

DST coercions were the last part of DST to land, and are still undergoing some changes.

Before stabilization, at the very least the API surface here needs some scrutiny from the libs team for naming and other conventions issues.

cc @nrc @gankro

Things to consider prior to stabilization

• Interaction with pin, see this internals thread and Pin is unsound due to transitive effects of CoerceUnsized #68015 for details.

[aturon]

@nrc, what's your sense of the status for these features? Do you feel ready to stabilize after the libs team takes a look?

[nrc]

My feeling (and it is really just a feeling, I have no data to back this up) is that DST coercions haven't yet got the use they need to prove themselves for stabilisation. I'd love to be wrong about this - if someone could show me a bunch of code doing stuff with DST coercions I'd be very happy. OTOH, I don't think there is anything fundamentally wrong with them, so it would not be a waste of time for the libs team to take a look.

[photino]

Why is the marker named Unsize? Unsized sounds better, since we already have Sized.

[arielb1]

@photino

It goes the wrong way around - for example, we have [i8; 2]: Unsize<[u8]> (and also [i8; 2]: Unsize<fmt::Debug>). We can swap the order of parameters - U: Unsized<T> if U is thean unsized version of T.

[rphmeier]

Can we move to stabilize this? It's been unchanged for 5 months and I've heard no complaints about it.

[Gankra]

I don't recall having any issues with this in libstd. The correct way to use this is basically a witchcraft incantation (mostly because these are under-the-covers things one never interacts with in real code), but as far as I know, there's know way to use it dangerously wrong? The whole thing Just Works.

I guess one thing I've never really thought about is why one needs to talk about whether the pointed-to value is unsizeable or whatever. Why can't one simply declare that pointer X is an unsizable one, and have all that junk automatic? Is this desirable to have for generic consumers...?

[jnicholls]

It's desirable for generic consumers of e.g. Arena allocators that allocate a Sized type that implements a trait unknown to the allocator, and the consumer wants to coerce the allocated result to an allocated trait object.

See https://gitlab.com/Bastacyclop/rust_arena/blob/master/src/lib.rs in the tests. It's a decent use case. How would you recommend doing this otherwise?

[stevenblenkinsop]

Is the lack of support for enums deliberate, temporary, or merely overlooked?

[aturon]

I'm nominating this for discussion at the next lang team meeting.

[Gankra]

@jnicholls maybe I'm missing something, but just mark the one pointer field that will be Unsized as coercable: https://gitlab.com/Bastacyclop/rust_arena/blob/master/src/lib.rs#L41

It seems to me that all the impl<...> CoerceUnsized for ... is trivially derivable from the claim that that field should be coercable.

[jnicholls]

@gankro Sorry I don't follow what you mean. Can you provide an example?