StableDeref trait into core #125048
StableDeref trait into core #125048
Conversation
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
| #[unstable(feature = "stable_deref_trait", issue = "123430")] | ||
| /// # Safety | ||
| /// | ||
| /// Any two calls to `deref` must return the same value at the same address unless |
There was a problem hiding this comment.
"same value at the same address" here is pretty vague, and it's unclear to me without reading the RFC thread what exactly that entails and how it compares to the stable deref trait crate. notably, the preconditions on the crate are currently not satisfied by Box because of the special strict aliasing rules imposed by it.
There was a problem hiding this comment.
The meaning of "same value" is that the concrete type must not change. I copied the explanation in below. Was it unclear?
Here, "same value" means that if
derefreturns a trait object, then the actual type behind that trait object must not change. Additionally, when you unsize coerce fromSelftoUnsized, then if you callderefonUnsizedand get a trait object, then the underlying type of that trait object must be<Self as Deref>::Target.Analogous requirements apply to other unsized types. E.g., if
derefreturns[T], then the length must not change. In other words, the underlying type must not change from[T; N]to[T; M].
The motivation for this requirement is that with trait objects, you could otherwise first return one struct, and then later return some wrapper struct that wraps the original struct using #[repr(transparent)].
library/core/src/ops/deref.rs
Outdated
| @@ -309,3 +309,25 @@ impl<T: ?Sized> Receiver for &T {} | |||
|
|
|||
| #[unstable(feature = "receiver_trait", issue = "none")] | |||
| impl<T: ?Sized> Receiver for &mut T {} | |||
|
|
|||
| #[lang = "stable_deref"] | |||
There was a problem hiding this comment.
This shouldn't be made into a lang item until it's actually used by the compiler. I feel like having unused lang items is not desirable.
There was a problem hiding this comment.
is there any chance of us somehow managing to check and error in that case?
There was a problem hiding this comment.
thinks okay the moment this left my hands the answer came to me as "probably not usefully" (it would only be one more formality-tier listing somewhere and someone will just add it to that).
There was a problem hiding this comment.
I think the use of it is rather imminent. Ideally with #123472 this would go into the trait bounds that #[derive(SmartPointer)] generates.
There was a problem hiding this comment.
I came to my right sense! I have dropped the lang term here.
dingxiangfei2009
force-pushed
the
stable-deref
branch
from
711777b
to
269eff8
Compare
This comment has been minimized.
This comment has been minimized.
dingxiangfei2009
force-pushed
the
stable-deref
branch
2 times, most recently
from
9a5dbc0
to
1795d68
Compare
dingxiangfei2009
force-pushed
the
stable-deref
branch
from
1795d68
to
77f8779
Compare
cc @Darksonn @wedsonaf @ojeda
This is a draft PR to introduce a
StableDereftrait as a possible answer to the unsoundness problem raised in the RFC draft rust-lang/rfcs#3621.We can follow up discussion in Zulip stream.