lint assigning to fields of an uninitialized struct

[oli-obk]

https://users.rust-lang.org/t/assigning-to-uninitialised-struct/6366/5

struct Point {x: u32, y: u32}

let mut p: Point;
p.x = 0;
p.y = 92;

// p is fully initialized, but can't use yet (unimplemented: https://github.com/rust-lang/rust/issues/21232)

and

struct Point {x: u32, y: u32}

let mut p: Point;
p.x = 0;

// p is partially initialized. access to `p.x` is ok, but access to p will error

[matklad]

access to p.x is ok, but access to p will error

Access to p.x is currently not allowed as well

[mcarton]

So there is no way to use that whatsoever?
Looks like rustc's own unused_variables and/or unused_assignments lints should be improved and warn on such code.

[Michael-F-Bryan]

This recently came up on the user forums where a user was trying to assign to fields individually to "initialize" something.

Quoting myself:

I’d actually vote for assigning to fields individually before initialization to be a compile error (or at least a default-on warning) because it’s a great way to shoot yourself in the foot. It’s usually an anti-pattern in Rust anyway.

There should probably be a lint which detects where someone has declared a variable, then tried to initialize it, or its fields individually, later on.

i.e.

struct Point {x: u32, y: u32}

let mut p: Point;
p.x = 0;    // <- warning: assigning to field of uninitialized variable. 
            //   help: try to initialize with `let p = Point { ... }` instead.
p.y = 92;

// this also a C-ism and should be a warning in straight-line code (i.e. not forward 
// declaring before initializing in a loop or if statement)

let p: Point; 
p = Point { x: 7, y: 42 };   // <- warning: unnecessary forward declaration followed by an assignment
                             //   help: prefer to initialize with `let p = Point { ... }` instead.

[llogiq]

I would be careful here – while it's an anti pattern in most circumstances, there are occasions where it is actually useful to be able to defer parts of initialisation. OTOH, I personally haven't seen this come up often in code, but then again, I often adopt a rather functional stance around initialisation anyway. I'd absolutely would support this as a restriction lint.

[camsteffen]

It seems the compiler does not allow such code anymore.