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

**URL:** <https://internals.rust-lang.org/t/in-out-uninit-references-is-it-time-yet/6792>\
**Category:** Uncategorized\
**Created:** [February 20, 2018, 2:11pm UTC](https://internals.rust-lang.org/t/in-out-uninit-references-is-it-time-yet/6792 "2018-02-20T14:11:57Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![canndrew](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/canndrew/32/1676_2.png) [@canndrew](https://internals.rust-lang.org/u/canndrew)\
**Post date:** [February 20, 2018, 2:11pm UTC](https://internals.rust-lang.org/t/in-out-uninit-references-is-it-time-yet/6792/1 "2018-02-20T14:11:57Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![oli-obk](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/oli-obk/32/3168_2.png) [@oli-obk](https://internals.rust-lang.org/u/oli-obk)\
**Post date:** [February 20, 2018, 2:14pm UTC](https://internals.rust-lang.org/t/in-out-uninit-references-is-it-time-yet/6792/2 "2018-02-20T14:14:46Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Tom-Phinney](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/tom-phinney/32/3299_2.png) [@Tom-Phinney](https://internals.rust-lang.org/u/Tom-Phinney)\
**Post date:** [February 20, 2018, 2:19pm UTC](https://internals.rust-lang.org/t/in-out-uninit-references-is-it-time-yet/6792/3 "2018-02-20T14:19:05Z")

</div>

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` `ident`s.

---

<div class="post-metadata">

**Author:** ![canndrew](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/canndrew/32/1676_2.png) [@canndrew](https://internals.rust-lang.org/u/canndrew)\
**Post date:** [February 20, 2018, 2:22pm UTC](https://internals.rust-lang.org/t/in-out-uninit-references-is-it-time-yet/6792/4 "2018-02-20T14:22:46Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mikeyhew](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/mikeyhew/32/2270_2.png) [@mikeyhew](https://internals.rust-lang.org/u/mikeyhew)\
**Post date:** [March 3, 2018, 11:04pm UTC](https://internals.rust-lang.org/t/in-out-uninit-references-is-it-time-yet/6792/5 "2018-03-03T23:04:29Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mikeyhew](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/mikeyhew/32/2270_2.png) [@mikeyhew](https://internals.rust-lang.org/u/mikeyhew)\
**Post date:** [March 3, 2018, 11:07pm UTC](https://internals.rust-lang.org/t/in-out-uninit-references-is-it-time-yet/6792/6 "2018-03-03T23:07:33Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\
**Post date:** [March 25, 2019, 8:29am UTC](https://internals.rust-lang.org/t/in-out-uninit-references-is-it-time-yet/6792/7 "2019-03-25T08:29:40Z")

</div>

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
