Goal: Accept partial initialization + use of records created via such

[pnkfelix]

Spawned off of #21232

In the long-term, we want to accept code like this:

struct S { x: u32, y: u32 }
fn main() { let mut s: S; s.x = 10; s.y = 30; a_use_of(&s); another_use_of(s); }
fn a_use_of(_s: &S) { /* ... */ }
fn another_use_of(_s: S) { /* ... */ }

We probably also want to start accepting this too:

struct S { x: u32, y: u32 }
fn main() { let mut s: S; s.x = 10; a_use_of_field(s.x); }
fn a_use_of_field(_x: u32) { /* ... */ }

(But that second example is more debatable. I don't think there's any debate about the first example.)

---

See #54986 for the short-term goal of rejecting all partial initializations until we can actually use the results you get from partial initialization.

[leonardo-m]

fn main() { let mut s: S; s.x = 10; a_use_of_field(s.x); }

If there's an invariant of the struct fields you can't use one struct field before all of them are initialized.

[pnkfelix]

I think @leonardo-m 's previous comment is meant to be an argument against accepting the code snippet they quoted.

Here are my main responses to that:

• Usually if there's some sort of invariant of the fields in a struct, it is enforced via privacy. (I.e., by making the fields non-pub, and making sure your public API upholds the invariant of interest.) This feature has no effect on that methodology.
• One big instance where struct invariants are super important is destructors: You don't want to get into a situation where a struct is only partially initialized and then its destructor gets called. Or rather, if the language allowed that, it would be basically impossible to write the code for a destructor. Rust already has a rule ensuring that you cannot move out of the fields of an ADT that implements Drop. This feature has no effect on that rule, either.

[pnkfelix]

tagging as NLL-deferred because we know we aren't going to try to implement this as part of the 2018 edition.

[pnkfelix]

@Centril has an in-progress draft of an RFC here: Centril/rfcs#16

[pnkfelix]

Re-triaging for #56754. P-low since any change here deserves a (currently "unwritten" or at least unposted) RFC.

[jethrogb]

There are some concerns about the current state of this in #60450

[tmandry]

How should we handle yielding from a generator while a local variable is partially initialized? e.g.

let mut gen = || {
  let mut x: (i32, i32);
  x.0 = 11;
  yield;
  x.1 = 22;
}

I'd prefer that this wasn't allowed when generators stabilize. It would simplify some layout code and potentially enable more optimizations. It's possible we decide to allow it eventually, but I'd rather not be locked into that decision from the start.

Note that I'm fine with allowing this in cases where the local is not stored in the generator (i.e. it is never used after the yield). This is only useful in the case of the second example from the issue description.

cc #60889