rfcs
rfcs copied to clipboard
rust-lang
de-RFC: Remove unsized_locals
I hope that this won't affect feasibility of #2884 (basically unsized_return).
It'd be cool if unsized_return could return into some future unsized_local, which sounds impossible with the alloca crate. An unsized_local that's less natural feeling sounds reasonable though. Anyways, the alloca crate has only three dependents, so maybe nobody cares enough.
I think de-RFCing the local variables part of this makes sense.
The original FCP was
I am not recommending an experimental RFC because I don't think we'll be making vast changes to the technical plan laid out here
But it seems like what we'd ended up hitting is that we really do need a fairly drastic re-work of how this works internally (since we don't have a MIR semantic for it) and plausibly also a re-work of how the syntax should behave (because we don't necessarily want this to silently happen).
Notably, like how the type ascription de-RFC wasn't a "we don't want type ascription at all" statement, I don't see this de-RFC as a statement that "we don't want allocas ever". If a feature with similar motivation comes back that's fine; this is just recognizing that the current state here doesn't seem to be stabilization-track and probably getting there deserves a new RFC.
My understanding is that this de-RFC is intentionally not touching unsized_parameters, which sounds appropriate to me. [EDIT: the RFC has been updated to say this very directly as well.]
@rfcbot fcp merge
Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
- [x] @joshtriplett
- [ ] @nikomatsakis
- [x] @scottmcm
- [ ] @tmandry
- [ ] @traviscross
Concerns:
- clarify-what-is-normative (https://github.com/rust-lang/rfcs/pull/3829#issuecomment-2941831706)
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. See this document for info about what commands tagged team members can give me.
While I'm OK with de-RFCing this, as probably I do want someone to write a fresh RFC, if we were to actually do this[^1], that made the case for how this should be done in the context of Rust as it is today, I don't want to commit to the following as a normative position:
Which is where we get to the major argument of this RFC: The
unsized_localsfeature integrates far too naturally into Rust. This makes the feature very easy to use, and especially easy to use accidentally.
Maybe that's correct, maybe it's not (as @Jules-Bertholet is arguing above). Probably I'd want to see an RFC arguing the case for what the right approach is (and read through the threads of all the prior RFCs), and I don't want to prejudge that.
In accepting an RFC, we generally aren't necessarily accepting the motivation or other non-normative sections as the position of the team, so perhaps I could check a box anyway. But there's a lot of normative-sounding language in this RFC, e.g.,
As a dangerous feature, dynamic stack allocation must be explicit and obvious - and
unsized_localsmakes it implicit by design. Therefore,unsized_localsmust go.
and it's not clear to me what the intended normative sections are. If this can be adjusted a bit so that it's clear that this RFC isn't committing normatively to this, but is rather raising this as one item that a future RFC should clearly speak to, and that the position taken here is the author's only, then I'll happily check a box.
I'd be happy both to do that and for @Jules-Bertholet or others to pursue an experiment to see if dynamic stack allocation can be done correctly in Rust, and to explore the best way to expose that in the language.
[^1]: ...after an acceptable experimental implementation were to be done.
@rfcbot concern clarify-what-is-normative
As mentioned, I'd like to avoid taking a normative position on how this might be done in the future, but in any event, we should clarify what exactly is normative here and therefore what our proposed FCP represents, so I'll file a concern to that effect.
It'd be OK, I think, if the only normative aspect of this RFC is that, by virtue of this de-RFC, someone needs to write a new RFC in order to eventually stabilize this.
Which is where we get to the major argument of this RFC: The
unsized_localsfeature integrates far too naturally into Rust. This makes the feature very easy to use, and especially easy to use accidentally.Maybe that's correct, maybe it's not (as @Jules-Bertholet is arguing above).
To be clear, though I think the RFC’s language on this is too strong, I do agree that there is a real and serious concern here, and it would have to be addressed before stabilization.
It'd be OK, I think, if the only normative aspect of this RFC is that, by virtue of this de-RFC, someone needs to write a new RFC in order to eventually stabilize this.
I fully agree with this, this would address all my objections.
@Noratrieb Do you have what you need to address the concern above? AFAICT the RFC hasn't been updated since that was filed.
Apart from memory of this RFCs existence, which was evidently severely lacking in the last two months, yeah. I'll add it within the next week.
@traviscross I have pushed cff645d5f3d510e3f56692579e46b2d5201aa989, does that address your concerns?
No, not quite. It says, e.g.:
Alternatively, the existing design of
unsized_localscould be RFCed again, if such an RFC was able to work around all the problems. This RFC merely unaccepts the previousunsized_localsRFC, it does not necessarily banishunsized_localsfrom existence forever.
But part of what this RFC is doing is setting out an opinion of what those problems are, so it almost sounds normative to suggest that those same problems would need to be worked around for another RFC to be accepted. E.g.:
As a dangerous feature, dynamic stack allocation must be explicit and obvious - and
unsized_localsmakes it implicit by design, a major downside of this feature that has not been addressed in prior RFCs.
I want to be clear that we're not accepting as a normative position that "dynamic stack allocation must be explicit and obvious". Maybe it should, maybe it shouldn't, but that's not a position I think we need to take to de-RFC this.
Probably I'd just do more to mark some sections as non-normative and then explicitly set out that the single normative effect is to unaccept the existing RFC such that someone would need to write a new one and have that accepted.
If you want (and are patient for me to get to it), I'm happy to take a pass at marking things clearly here. I know it might just be difficult to guess what I'm looking to see.
Is there still some "commitment" to the original RFC motivation of passing unsized values? Ala
fn takes_closure(f: dyn FnOnce()) { f(); }
It feels like more explicit schemes might break this, and and require borrows here, which maybe fine.
Is there still some "commitment" to the original RFC motivation of passing unsized values? Ala
fn takes_closure(f: dyn FnOnce()) { f(); }It feels like more explicit schemes might break this, and and require borrows here, which maybe fine.
RFC 1909 proposes something similar for unsized arguments and VLA
See the RFC.
This does not have a negative effect on features that feature unsized values in function signatures like unsized_fn_params. Their behavior is much more clear and they are implemented differently. In fact, unsized_fn_params is currently needed in the standard library to implement Box<dyn FnOnce()> as FnOnce()>.