The size of `(T, Infallible)` is not zero

[EFanZh]

Since Infallible is an empty type, I expect (T, Infallible) also be an empty type, thus they should have the same size. But I noticed that (T, Infallible) have the same size as T, so currently, we have

• mem::size_of::<Option<Infallible>>() == 0
• mem::size_of::<Option<(u32, Infallible)>>() = 8

I guess this is because Rust treats empty type to have size 0, so the size of (T, Infallible) is size of T plus size of Infallible equals size of T. May be we can use something like Option<usize> to represent the size of a type internally, where None means the size of an empty type, in this way, we can distinguish empty types from zero sized types. For example, internally, we can have a function like:

fn internal_size_of<T>() -> Option<usize> { ... }

To keep the current behavior of mem::size_of, it can be implemented as:

fn size_of<T>() {
    internal_size_of::<T>().unwrap_or(0)
}

[vacuus]

(I don't claim to be authoritative on this topic)
(I'm using ! but this applies to Infallible just as well)

tl;dr:
If you were thinking that size_of::<Option<!>>() == 0 should imply size_of::<Option<(u32, !)>>() = 0, I don't believe there is currently any guarantee for that, and, in any case, the logic for each would be distinct.

The Rustonomicon, which you linked, doesn't seem to guarantee anything about the size of (T, !), and the doc page certainly doesn't. In any case, I don't think it would make sense for the size of (T, !) to be 0. Just like how Result<T, !> effectively removes the Err variant because Err(!) can't be instantiated, (T, !) should effectively be a one-member tuple because the programmer is effectively telling the compiler that the second member can't be instantiated. Monomorphization doesn't completely eliminate Result<T, !> because no such statement has been made about the Ok(_) variant, and similarly, (T, !) makes no statement about the instantiability (lol) of the first member.

Please correct me if I'm wrong!

[scottmcm]

This is intentional; see #49298

[RalfJung]

Indeed, the size of (T, Infallible) was 0 at some point and that was critical soundness issue and got fixed.

So I think this issue should probably be closed. The one thing we could do here is improve documentation of this problem, but I am not sure where such docs would go.

[vacuus]

Perhaps the same page of the Rustonomicon that @EFanZh linked at the top?

[RalfJung]

This is intentional; see #49298

As @Ericson2314 pointed out, the example that made this unsound does not compile any more. NLL does not accept thus code so when NLL became mandatory on all editions, this stopped working. That decision was made here; there is an open issue at #54987 to re-accept such code.

I will hence re-open this issue to track potentially doing the layout optimization again. That said, clearly that is in conflict with #54987, and there might be other soundness issues as well that I am missing.

[RalfJung]

Also see the discussion starting at #54987 (comment) for other potential soundness concerns with making (!, T) have size 0. In particular, code like this still works:

let x: (String, !) = (mk_string(), panic!());

and it needs to store the string somewhere (and drop it).

Currently a temporary is created for this (and the tuple constructor is not even anywhere to be seen in the MIR), but I am not sure how intentional that is.

[taralx]

What is the challenge in making -∞ the size of uninhabited types? It makes the math work:

size_of::<!>() = -∞
size_of::<Option<!>>() = LSE(-∞, 0) = 0
size_of::<(u32, !)>() = 4 + -∞ = -∞
size_of::<Option<(u32,!)>>() = LSE(4 + -∞, 0) = 0

[RalfJung]

-∞ is not a number :)

And anyway computing the layout of a type involves a lot more than computing its size, so it's not like somehow changing the size of ! would magically make anything easier. The trouble isn't having layout computation make (!, i32) a ZST -- that in fact was already implemented at some point in the past, but got reverted due to soundness issues (and that was referenced above: #49298). The trouble is figuring out if doing so will cause problems elsewhere.

[Ericson2314]

-∞ is I still think morally on the right track, namely we should not conflate the layout of ! and (). Calling them both "ZSTs" just adds more special cases later. What we have is something like

struct InhabittedLayout { size: usize, align: usize }
enum Layout {
   Uninhabitted,
   Inhabitted(InhabittedLayout),
}

and thus a Inhabitted(InhabittedLayout { size: 0, align: 0 }) vs Uninhabitted distinction.

Per https://en.wikipedia.org/wiki/Tropical_geometry layout and the divisibility lattice, layout computation does have nice algebraic properties.

[RalfJung]

we should not conflate the layout of ! and ()

Yeah, and they have different Layout in Rust. That doesn't need to be reflected in size and alignment though.

[Ericson2314]

let x: (String, !) = (mk_string(), panic!());

My understanding is we evaluate the right and side, it diverges, and so we don't care what the left hand side looks like.

let (a, b): (String, !) = (mk_string(), panic!());

Splitting into separate lets doesn't change the behavior of the program, even if it does expose a new location where we didn't have one before.

#![feature(never_type)]

fn main() {
    let x: !;
    println!("asdf");
    x = panic!();
}

Does work today, and cracks me up.

Basically, for spooky reasons of polarity of the sort discussed in many papers of at https://www.pauldownen.com/#publications , I think ! really is just a valid type for "(r) values" (not unlike the original restriction, ironically enough!) and so it "nukes" any locations it touches, per the homormophic layout rules.

The problem with things like let x: !; is that an unitialized variable I think is "morally" a different type Uninitialized<A> instead of A (and the "moral types" of locations changes throughout the control flow graph). When A is inhabited, Uninitialized<A> and A have the same layout, but when A isn't they don't because the whole point of Uninitialized<A> is that it is a "fat" (), and so always inhabited. This absurdity is why uninitialized uninhabitted types should just be banned --- do that, and I will bet a few beers all problems go away.

MaybeUninit, being union, is always inhabited, so MaybeUninit<!> is fine but useless, and MaybeUninit<(!, usize)> is fine but just as useless. (Still cannot do anything with second field of the tuple because the tuple is a ZST, too bad.) This might upset people, but follows from the rules so I am OK with it.

[RalfJung]

This absurdity is why uninitialized uninhabitted types should just be banned --- do that, and I will bet a few beers all problems go away.

I am suspicious of any calculus that ends up not being able to treat uninhabited types properly. let x: T; should work in generic code for any T, ergo it should work for ! as well. If that is a problem for some formal calculus, IMO that shows a flaw in the calculus.