Consider aggregate types containing unconstructable types to also be unconstructable

[eira-fransham]

Currently Option<!> is 0-sized, but Option<(T, !)> isn't, despite the fact that the Some variant of the latter is unconstructable. If this were fixed then you could implement PhantomData in userland as:

type PhantomData<T> = Option<(T, !)>;

instead of it being special-cased in the compiler.

[scottmcm]

This has been discussed before. The complicated case is this one:

let x: (u32, !);
x.0 = 100;

That compiles today by actually writing the 100 into the first 4 bytes of the stack slot.

[Centril]

That compiles today by actually writing the 100 into the first 4 bytes of the stack slot.

Thankfully, it does not really (playground):

#![feature(never_type)]

fn main() {
    let mut x: (u32, !);
    x.0 = 100;
}

[scottmcm]

@Centril That's absolutely what we tell LLVM to do, and what it does in debug mode (godbolt):

pub fn foo() {
    let x: (u32, !);
    x.0 = 100;
}

define void @_ZN7example3foo17hd23b272186309284E() unnamed_addr #0 !dbg !5 {
  %x = alloca { [0 x i32], i32, [0 x i8], { [0 x i8] }, [0 x i8] }, align 4
  %0 = bitcast { [0 x i32], i32, [0 x i8], { [0 x i8] }, [0 x i8] }* %x to i32*, !dbg !8
  store i32 100, i32* %0, align 4, !dbg !8
  ret void, !dbg !10
}

example::foo:
        push    rax
        mov     dword ptr [rsp], 100
        pop     rax
        ret

LLVM may optimize it sometimes (like it does let mut x: u32; x = 100;), but what I said is what we emit.

[Centril]

@scottmcm Sure, but this will eventually stop compiling so what we emit to LLVM is irrelevant because it won't reach LLVM and will fail during type checking instead.

[hanna-kruppe]

We actually deliberately went from considering this a ZST to not considering it a ZST to fix bugs, see #49298

That issue also contains an example (I've seen more but I think most discussion is effectively lost in old chat protocols) that highlights that not uninhabited should not imply ZST, even if partial initialization is ruled out.

[vi]

Maybe attempts to write to a sibling of an uninhabited field should be just no-ops?

With partial initialization layout adaptaions, ! loses its mathematical beauty and becomes just a fancier ZST.

! from my imagination turns Vec<!> and HashMap<i32,!> into ZSTs. #50622 seems like a step away from it.

If ! were added to the language at the same time as (), would it have pandered to partial initialisation?

[hanna-kruppe]

cc rust-lang/unsafe-code-guidelines#79 and rust-lang/unsafe-code-guidelines#216 which also contain relevant discussion.

[vi]

Maybe it can be opt-in for structs?

struct A {
    a: u32,
    b: !,
}

#[no_partial_initialisation]
struct B {
    a: u32,
    b: !,
}


fn main() {
    println!("{}", std::mem::size_of::<A>()); // 4
    loop { let _ = A { a: 23, b: break }; }
    
    println!("{}", std::mem::size_of::<A>()); // 0
    loop { let _ = B { a: 23, b: break }; }   // compile error
}