partially initialized structs in local variables, similar to partially moved structs, perhaps should be possible

[comex]

Here are two examples where currently a dummy value for a struct field is needed, but the compiler could allow it to be safely left uninitialized by noticing that it's always initialized before being used externally. This is quite analogous to partially moved structs, where the compiler currently allows moving out fields as long as you put them back before using the struct externally (even if the latter is in a loop, as in the second example); but in this case the struct would start in a "partially moved" state.

Even though I think this is a fairly unusual use case (at least, as long as it doesn't allow calling methods in the partially uninitialized state), the added semantic complexity is pretty minimal, so I think it's worth considering.

use std::cell::RefCell;
struct Foo<'a> {
    a: RefCell<int>,
    b: &'a RefCell<int>,
}
struct Bar {
    a: int,
    // assume some other stuff
}
fn main() {
    // Case 1: assigning a reference to point to the struct itself (somewhat
    // limited since the struct can't be moved, but potentially useful)
    let mut foo = Foo {
        a: RefCell::new(1),
        b: /* dummy */ &RefCell::new(1),
    };
    foo.b = &foo.a;

    // Case 2: assigning inside a loop
    let mut bar = Bar {
        /* dummy */ a: 0,
    };
    for &a in [1, 2, 7].iter() {
        bar.a = a;
        // call some method on bar
    }
}

[Gankra]

What happens if I panic between making the struct and fully initializing it?

[comex]

The same thing as in the partially moved case.

[reem]

Also, the above example won't work anyway, since you could move foo.a while foo.b still exists.

[comex]

If I simulate an uninitialized state by turning b into b: RefCell<&'a RefCell<int>> (just to make it non-Copy; nothing important about the outer RefCell), and partially moving b immediately after creating the struct, the compiler is okay with it. After filling in foo.b again, I can call &self methods on the object and whatnot. So I think it should work...

[pcwalton]

I believe @comex is correct and there is nothing semantically wrong with this.

[crlf0710]

Now we have MaybeUninit, which covers these use cases. Maybe this can be closed now. @Centril

[CryZe]

OP is about doing so safely, while MaybeUninit is doing so unsafely. MaybeUninit certainly works, but having the language recognize that the use cases shown are safe would be much better.

[shepmaster]

See also Goal: Accept partial initialization + use of records created via such #54987