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.