`&in`, `&out`, `&uninit` references: is it time yet?


#1

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.


Out argument for efficient initialisation
#2

I don’t think it fits the “boring” roadmap of 2018, because these references are way too interesting and fancy and new and cool and everything!

I’d like to see them, too, but I don’t think they quite fit the plan for this year.


#3

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 var idents.


#4

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.


#5

@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).


#6

As for whether it’s time, these might be something we can prototype with arbitrary self types, once they are sorted out