-
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
[RFC] core::marker::Freeze
in bounds
#3633
base: master
Are you sure you want to change the base?
Conversation
IIRC @joshlf was also asking about exposing Freeze; maybe they can help provide some more motivating examples. Currently there's only really one. (I don't understand the "key of a map" note, and the RFC doesn't explain it in more than 5 words either.) |
The main reason for not stabilising I don't think that just stabilising it for bounds affects this concern. The issue isn't the trait itself being exposed in the library, but APIs having to worry about whether they are |
A bound is exactly what one is worried about here? If one writes a function This is exactly the same as Fundamentally there are some things the compiler only lets you do with (Or did I misunderstand what you mean? It sounded a bit like you're saying just stabilizing the bound means we don't have to worry about the concern. But upon re-reading I am less sure.)
Letting people write |
Sure! If you want to dive deeper, look at uses of On zerocopy stable, we provide traits like However, this is overly-restrictive. The "no Another restriction is that some authors want to use Our solution in the upcoming zerocopy 0.8 is to add a separate * Currently, |
I should clarify, what I meant here was the adding of stuff like Not the ability to make something |
For another "motivating example", One possible alternative that would "work around" the semver issue would be to have Footnotes
|
Yeah that could work -- as you say, the existing |
core::marker::Freeze
in boundscore::marker::Freeze
in bounds
Thanks for writing this up. I appreciate the effort that went into it and the desire to push things forward. But... I think this RFC needs a fair bit of work. After reading it, I'm still left with some very fundamental questions (and I expect these to be answered in the RFC):
|
IIUC, we couldn't do that today since If we decide to keep it a type property - ie, the absence of
|
So if we want to expose the |
@joshlf For the purpose of |
IMO the main advantage is that An additional advantage is that there would be only one trait to encode the invariant.
For my sketch of Footnotes
|
The most important reason is that the compiler can see into the internals of types in the standard library. For example, I filed this extremely silly issue because there's technically no guarantee provided to code outside of the standard library that Besides that, here are some other reasons:
|
Thanks to everyone taking an interest in this RFC. First, a quick apology for it starting up so half-assed, I clearly underestimated the task. I started this RFC as a knee-jerk reaction to 1.78 merging the breaking change the RFC mentions without providing a way for const references to generics to exist. I'm still committed to getting this to move forward, but I have limited availability for the next 2 weeks, so please bear with me as I rewrite this entire thing to the standard I should have started it with. I would really appreciate getting some early feedback on the direction people around here would like to see this RFC take regarding:
Sorry for my high latency for the beginnings of this RFC. I really appreciate all the feedback you can give, and would like to mention that PRs to this PR's branch are very welcome :) |
@p-avital happy to hear that you're not discouraged by all the extra work we're throwing your way. :)
Even if Freeze was recursive, types can use raw pointers or global |
@p-avital It's hard for me to give you good feedback here because I think I lack a fair bit of context. Most of the discussion (and the RFC itself) seems to be very high context here, and it's context that I don't have. With that said, I can say that adding a new auto/marker trait is a Very Big Deal. It's not just that "auto traits = bad," but that adding a new one comes with very significant trade offs. That doesn't mean that adding one is impossible, but it does mean, IMO, that adding one needs to come with significant benefits. Or that it's the only path forward for some feature that most everyone deems to be essential. From the discussion, it sounds like there are alternatives. So those alternatives, at minimum, should be explored. |
@BurntSushi note that the |
@RalfJung Yikes. OK. Thank you for pointing that out. That's exactly the kind of context I was missing. |
Hello again everyone, I'm back and ready to keep pushing on this. I've already committed the result of every suggestion that seemed immediately actionable to me. It appears to me that 2 remaining roadblocks are:
As an aside to maintainers around here, is there a chance we can slip this in 1.79 if we're quick enough about resolving those questions, or is the release cycle already too far gone? |
One remaining question in my mind. I'm not sure whether this would affect the design, but it might. Do we want to leave open the possibility of implementing struct Foo<T>(UnsafeCell<T>);
static_assertions::assert_not_impl_any!(Foo<u8>: Freeze);
static_assertions::assert_impl_all!(Foo<()>: Freeze); This would make ZST-ness (or "zestiness", as @jswrenn prefers to pronounce it) a semver-visible property, but that's already true for some types (e.g. Obviously a lot of thorny questions to work out - I'm not talking about working them out here, but just making sure we don't foreclose on the future possibility. Maybe add it to the "future possibilities" section of the RFC. |
@joshlf, I believe that possibility is permitted. See the reference level explanation's proposal of
This explanation is phrased in terms of mutability-without-indirection, rather than the presence of absence of That said, the current implementation of |
Yeah, so I think we'd just want to update the proposed doc comment to be more explicit about the fact that |
1.79 is in beta and not going to receive any new features. If an implementation of this got merged before June 7th, it would be part of 1.80. But given t-lang capacity and the 10-day FCP period for the RFC, I don't want to raise any false expectations -- that's very unlikely. If it makes it into 1.81 (which branches on July 19th) that would be extremely fast by RFC standards, but we can possibly used the fact that this fixes a regression as an argument for prioritizing this in t-lang discussions. (I can't make that call, I am not on the lang team.) Rust is moving too fast for some people's liking, but not that fast. |
I think it does. I think a nice way to allow for this to fit the RFC nicely would be to:
|
Bunch of grumps! 🥲
So at least 2 more months of sad |
I'm afraid it's going to be more than 2 months -- 1.81 branches on July 19th, i.e. that's when the 6-week beta period starts. It is going to be released on Sep 5th. I hope this is not too much of a downer, your help here is much appreciated! It's just generally not good idea to rush irreversible decisions that the entire Rust community will have to live with forever. |
Honestly, the downer was 1.78; now I'm just fired up to get that situation resolved! I fully understand wanting to do due diligence on these things, I've been hurt by both ends of the stabilization stick before (looking at you, forever ABI-unstable But just to keep a sense of urgency: not making it to 1.81 would be a downer 😛 As an aside: I've updated the proposal to include |
Hiya @RalfJung (sorry if the ping is a bit cavalier), do you see any work this RFC still needs before it can enter FCP? :) |
That's a question for t-lang, not for me. :) I have nominated the RFC to be discussed by the lang team. |
Co-authored-by: Ralf Jung <[email protected]>
Co-authored-by: Gábor Lehel <[email protected]>
Hi @RalfJung, sorry for pestering you, any updates on the RFC's status? Let me know if there's a more appropriate place/person to follow up with on this RFC :) |
It's in the lang team's nomination queue. They probably have several dozen items in that queue so we'll have to see when they get around to discussing this RFC.
|
@@ -194,3 +217,4 @@ Note that `core::marker::PhantomData<T>` is `Freeze` regardless of `T`'s `Freeze | |||
- Adding a `trait Pure: Freeze` which extends the interior immutability guarantee to indirected data could be valuable: | |||
- This is however likely to be a fool's errand, as indirections could (for example) be hidden behind keys to global collections. | |||
- Providing such a trait could be left to the ecosystem unless we'd want it to be an auto-trait also (unlikely). | |||
- `impl !Freeze for T` could be a nice alternative to `PhantomNotFreeze`. However, this would be a significant language change that needs much deeper consideration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's worth mentioning that these are not the same, and so one may not be a straightforward alternative for the other.
Including a PhantomNotFreeze
field removes the Freeze
impl for the type. impl !Freeze for T
expresses a guarantee that there will never be a Freeze
impl for the type.
The actually-equivalent language feature would have to be something like impl ?Freeze for T
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right you are, if we stick to the "impl !Trait for X
means that impl Trait for X
requires a major bump" interpretation (which is something I'd really enjoy to have), they do indeed yield different results
Co-authored-by: zachs18 <[email protected]>
Rendered