-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
specify that CoerceUnsized should ignore PhantomData fields #1234
Conversation
+1 Alternatively we could allow this for all ZSTs, and just implement for PhantomData for now. Special casing PhantomData is pretty much an implementation detail. Could we approximate zero-sized == no non-zero-sized fields? Presumably we'd need to wait for the drop flag to disappear. Then just assert that we were right in trans. |
👍 |
I agree with @nrc that the text shouldn't be specific to |
I guess the question is whether unsizing two fields is forbidden for semantic or implementation (offsets fall over with multiple unsized fields) reasons -- if it's semantic then PhantomData is the only type we really know doesn't matter. If it's implementation then presumably all ZSTs should be fine. |
if we're going to patch in place, can we make a section at the end entitled something like "Updates since being accepted" and record the changes |
@nikomatsakis done. |
So, regarding the specialization to @eddyb thoughts? |
@nikomatsakis I would suggest limiting this as much as possible, otherwise it might allow writing |
@eddyb can you explain what you mean by "allow writing transmute in safe code"? (e.g., maybe give an example) Perhaps I have to refresh my memory of just which traits we're talking about here. |
@nikomatsakis The transmute remark was about the worst case, where arbitrary types are converted without an actual coercion, e.g: struct Foo<P, T>(Box<P>, T);
impl<P: Unsize<Q>, T, U> CoerceUnsized<Foo<Q, U>> for Foo<P, T> {} Though I doubt you had that in mind. |
We discussed this today in the language subteam meeting. The conclusion was that while many of us believe we can generalize DST coercions further (read: @nikomatsakis does, at least), we should not let the perfect be the enemy of the good. Therefore, we should take this RFC, and consider further generalizing the rules another time. |
Hear ye, hear ye. This RFC is entering final comment period. |
Ah, @gankro, can you amend the RFC to include as an "unresolved question" the extent to which coercion can be generalized to simply permit multiple fields to be coerced? |
@nikomatsakis done |
Huzzah. The lang subteam has decided to accept this RFC. Tracking issue rust-lang/rust#28239. |
Otherwise you can't have a
Smaht<T>(*const T, PhantomData<T>)
, which is problematic for drop check, which requires this annotation if Smaht owns the referrent (Box, Rc, Vec, etc..).See rust-lang/rust#26905 for some discussion.
You could arguably ignore all zero-sized fields, but it's currently hard for the compiler to do so (size is largely a trans notion, to my knowledge). Also maybe you actually want a generic ZST field that has some meaning beyond PhantomData?
A potential workaround to this problem would be
Smaht(*const u8, PhantomData<T>)
but this is entering a fairly degenerate state for the semantics of raw pointers. Although we're already in a bit of a degenerate state in that all Smaht pointers desire some level of mutable access, but are forced to use*const
to acquire the correct variance. We paper over that mess via Unique -- we could consider just embracing that and making Unique the only proper way to build Smaht pointers.Of course Unique is incorrect for Rc, but I plan on adding a Shared equivalent for Rc anyway which could have similar magicks.