In the past there’s been proposals to add new kinds of references for handling uninitialized data. This is a feature I’d really like and I think I could put together an RFC for it, but I’m wondering if it’s something that’s likely to get attention anytime in the near future or if the RFC would just collect dust.
Very briefly: my proposal would be to add three new kinds references:
&out T: data must be moved out from the reference before the end of the region, leaving the reference uninitialized.
&in T: the reference is initially uninitialized and data must be moved into it before the end of the region.
&uninit T: the reference is initially uninitialized and must be left uninitialized at the end of the region, but can be used as temporary storage in the mean time.
I think it’s possible to make these work alongside unwinding without needing linear types, though there may be complications I’m not seeing (discussions welcome!). I’m just wondering whether, with the other work that’s going on in the compiler at the moment, this is a good time to push this or whether to wait another year.
However, if this might happen in the future, it would make sense to include those three terms as at least reference-contextual keywords, which would make them unusable as varidents.
True, it might be better to make a decision on this sooner rather than later so that we know what keywords to reserve, even if we put off the actual implementation for a long time.
@canndrew just a thought. This is the first I’ve seen &in and &out discussed in the context of Rust, and they sound like pretty cool ideas. But it looks to me that you’ve got them backwards looks backwards to me: wouldn’t &in be something that you can read a value from, and &out be a place that you write a value to? As in incoming and outgoing? If the names are a source of confusion, maybe we should see if there’s better names (incoming and outgoing, readable and writeable, etc).