Lets discuss Inhabited trait

[arielb1]

Surprisingly enough, mem::uninitialized (and even mem::zeroed) are dangerous to use even with inhabited types. That’s why we are trying to stabilize MaybeUninitialized.

For example, references (&T) are not allowed to be null, so calling mem::zeroed::<&u32>() is pretty much instant UB and will cause your program to randomly break. If you just call mem::zeroed::<StructThatContainsAReference>(), your program might not randomly break now, but optimizer changes might cause it to break just as well. This is of course still a problem with uninitialized values, as they might end up being all zero.

If we reach a “status quo” position where we give let x : &u32 = mem::uninitialized(); a well-defined meaning (which I think we should as long as mem::uninitialized exists, given that this pattern is very common) then we can just as well give let x : T = mem::uninitialized(); the same meaning for T = !.

I think that this concern eliminates most of the necessity for an Inhabited trait.

[Ixrec]

I was under the impression that mem::uninitialized, mem::zeroed and mem::transmute have been considered error-prone/footgun-y/overly powerful APIs for a very long time (see arielb1’s post; none of those examples are new), and sometime around the introduction of unions it became clear that MaybeUninit and ManuallyDrop and similar types were just all-around better abstractions for most of the same use cases.

Therefore, I thought all this stuff about ! stabilization hitting a snag because uninhabited types conflict with mem::uninitialized and friends was merely a reason to speed up deprecating them, not the sole or primary reason we want to deprecate them in the first place.

I think this is the third or fourth thread I’ve seen that started from the premise that “they’re getting rid of mem::uninitialized just because of uninhabited types, and I disagree because …” and I still have no idea why so many people think that was the sole motivation.

[newpavlov]

I’m uncomfortable with ?Inhabited implying that an Inhabited bound is default-assumed

As you can see some users completely unaware about pitfalls associated with uninhabited types and write unsafe code accordingly, so requiring explicit opt-in will be a great fail-safe. Honestly I am more uncomfortable with the current status quo and I believe that MaybeUninit is a fig leaf, the only useful thing about which is ability to decouple uninitialized variable creation, writing into it and “converting” into desired type. And because creation of uninitialized variable and work on it usually tightly coupled I don’t see that much benefit in it. All pitfalls are still here, we just added one small step and hope that it will protect users from uninitialized pitfalls.

I’m also uncomfortable with assuming negative bounds and / or mutually exclusive traits will be a thing

Can you elaborate why you and @rkruppe wary about negative trait bounds?

struct Haskal(Box<Haskal>);

So should it be considered uninhabited according to the Inhabited trait?

I believe it’s very much inhabited type. (note that it compiles, and segfaults only at runtime) Essentially you’ve just created a recursive reference into heap. I think rule of the thumb here is: if mem::size_of does not return 0 it is inhabited type. (well, if we exclude “pathological types” like (u32, !), which I believe should be forbidden)

I don’t see this as valuable because inhabitedness is such a minor part of the potential problems you can hit with transmute.

As I’ve wrote earlier this proposal is not just and not as much about safety of transmute.

And transmute::<!, Void> and such are totally fine, so restricting both sides to be :Inhabited is overly aggressive anyway.

Can you provide a real use-case for such transmute call? Considering that with E=!:

match result { Ok(v) => { .. }, Err(e) => { .. } }

In error branch e will be considered inhabited type?

That’s a great reason to not expose inhabitedness in the type system, actually, since it’d be a breaking change to improve what it can detect.

See explanation earlier, IIUC the provided example has nothing to do with uninhabited types.

@arielb1

As I’ve wrote in the beginning of this post, I don’t think that MaybeUninitialized brings too much to the table, you just shift uninhabited type creation to the moment of flipping union to value variant. All hazard of generic code are still here, you’ve just covered it a bit. Yes, we can move unsafe block around, but dragons are still around the corner!

[Ixrec]

As I’ve wrote in the beginning of this post, I don’t think that MaybeUninitialized brings too much to the table, you just shift uninhabited type creation to the moment of flipping union to value variant. All hazard of generic code are still here, you’ve just covered it a bit. Yes, we can move unsafe block around, but dragons are still around the corner!

My understanding was that working with uninitialized memory always has proverbial dragons, the best we can hope to do is make the unsafe code easier to write correctly and see that it’s correct when reading, and the MaybeUninit abstraction is less error-prone precisely because it moves the unsafe blocks to the right place to achieve that. So… I guess I technically agree with what you said?

(I’m aware of proposals like &out references, but afaik those don’t cover all cases, just some of the most common ones)

See explanation earlier, IIUC the provided example has nothing to do with uninhabited types.

Could you link whatever this was more explicitly? I’ve just reskimmed the entire thread and didn’t see any useful examples of code that would benefit from an Inhabited trait, so I’m still missing what the motivation is supposed to be.

---

Meta note: I feel like ^this for a LOT of threads on this forum lately. We need to spend way more time on gathering and dissecting use cases and way less on debating these ideas in the abstract.

[Centril]

Can you elaborate why you and @rkruppe wary about negative trait bounds?

I’m concerned about making the assumption itself more than about negative trait bounds. What if we don’t end up adding negative trait bounds?

I believe it’s very much inhabited type. (note that it compiles, and segfaults only at runtime) Essentially you’ve just created a recursive reference into heap. I think rule of the thumb here is: if mem::size_of does not return 0 it is inhabited type. (well, if we exclude “pathological types” like (u32, !) , which I believe should be forbidden)

The segfault here implies that you’ve not constructed a valid instance of the type. This is thus not a valid example. If you somehow manage to construct a valid Haskal using safe Rust, that should amount to a soundness hole in the type system.

[newpavlov]

Could you link whatever this was more explicitly? I’ve just reskimmed the entire thread and didn’t see any useful examples of code that would benefit from an Inhabited trait, so I’m still missing what the motivation is supposed to be.

I was talking about notriddle’s Haskal example, which you’ve used as a false example of “breakage”. For examples see e.g. this post about Result. Also !Inhabited could be used to explicitly require uninhabited type in generic contexts. (I think there was a thread with request of the similar feature)

[Ixrec]

I was talking about notriddle’s Haskal example, which you’ve used as a false example of “breakage”.

I think that was @scottmcm, not me (I have no clue if it’s “false”, but I haven’t said anything about the Haskal thing).

[scottmcm]

All pitfalls are still here, we just added one small step and hope that it will protect users from uninitialized pitfalls.

I think this is a massive understatement.

Right now, it’s common to just let x = unsafe { mem::uninitialized() };, and I don’t blame anyone who does, as the interface pushes you in that direction. But that’s completely backwards from where the risk actually is.

Creating unintialized memory can, and should, be safe.

let x = MaybeUninit::default(); being safe is great. It’s like how let p = 53629 as *const _; is safe. Then the rules for uninitialized memory become really similar to those of pointers, where it’s unsafe to read instead of to create, since that’s where things actually go wrong. It’ll be great for RawVec<T> to be able to give a &[MaybeUnit<T>] instead of its current “well, here’s a pointer” – it could even Deref to that slice safely.

[newpavlov]

What if we don’t end up adding negative trait bounds?

Then it will be +1 trait in the row of Sync and co.

The segfault here implies that you’ve not constructed a valid instance of the type. This is thus not a valid example. If you somehow manage to construct a valid Haskal using safe Rust, that should amount to a soundness hole in the type system.

But why such condition on unsafe? If I’ll write struct with private members and no constructors, I doubt we should consider it uninhabited type. In my understanding you can construct Haskal type value, but due to the recursive nature you either get segfault (dereferencing invalid pointer) or stack overflow (if you’ll get reference cycle). I am not proficient in type theory so I don’t know how to express it strictly, maybe it’s a type with infinite value size (on abstract machine without segfault traps)?

I think that was @scottmcm, not me (I have no clue if it’s “false”, but I haven’t said anything about the Haskal thing).

Hm, apologies then. Looks I’ve misunderstood you somewhere.

[newpavlov]

Good point, your post probably should be part of the RFC motivation. Though in my experience usually I use uninitialized as part of a single unsafe block in which I handle filling data, but I understand pitfall described by you. Nevertheless I believe that issues around inhabited and uninhabited types are still here, and that Inhabited auto-trait is the best solution, which ideally should be in the language. In the MaybeUninit case it should be forbidden to create MaybeUninit<!>, which I don’t think can be done nicely without Inhabited bound.

[scottmcm]

In the MaybeUninit case it should be forbidden to create MaybeUninit<!>

Why do you think that? Calling MaybeUninit::<!>::default() is totally fine and safe.

Preventing it would have major costs, too. Like my RawVec example; it’s sound to have a Vec<!> today, which uses RawVec<!> internally, but if MaybeUninit<!> was disallowed, then RawVec<!> wouldn’t work either.

(Obviously you won’t be able to get a ! out unless someone put one in – which of course they can’t – but the requirements on Vec for that to be the case are no different than for any other type: you can’t get a String out of a Vec without putting one in, either. So there’s no need for extra ! restrictions.)

[notriddle]

I believe it’s very much inhabited type. (note that it compiles, and segfaults only at runtime)

Just because you can unsafe your way past the compiler doesn’t mean you’ve constructed a valid instance of the type. After all, you can transmute an instance of the enum Void {} type into existence, too, but we still call it uninhabited.

If constructing a box with zero is defined as having undefined behavior (which it is, for all boxes, not just the Haskal one), then zero does not inhabit the box type. If no values inhabit a type, then that type is uninhabited.

I think rule of the thumb here is: if mem::size_of does not return 0 it is inhabited type. (well, if we exclude “pathological types” like (u32, !) , which I believe should be forbidden)

That’s completely arbitrary. Inhabitedness is a degenerate case of the type system’s existing rules; enum Void {} is uninhabited because enums are required to be one of the type’s variants, and Void has no variants for it to be. Not because the size calculator deduces that no space needs to be allocated for it.

The fact that there are multiple ways to create an uninhabited type, beyond just the empty enums, is why I don’t want to bake uninhabitedness into the type system.

[newpavlov]

Why do you think that? Calling MaybeUninit::<!>::default() is totally fine and safe.

Yes, but getting value from it does not make sense. Same goes for Vec<!>, I’ve asked several times, but no one have provided any practical examples of why such “pathological types” should be allowed.

If constructing a box with zero is defined as having undefined behavior (which it is, for all boxes, not just the Haskal one), then zero does not inhabit the box type. If no values inhabit a type, then that type is uninhabited.

I can construct such Haskal with the Box which points to the memory in which is stored pointer, which points to the same memory. (i.e. pointer and stored value are equal) Practically it ends up in stack overflow, which was mentioned in my previous post. Does it count as a value of the Haskal type? Yes, this value will require infinite memory, but theoretically it’s a valid value, no?

The fact that there are multiple ways to create an uninhabited type, beyond just the empty enums, is why I don’t want to bake uninhabitedness into the type system.

So shouldn’t we properly specify ways to create uninhabited types as an improvement of Rust type system instead of averting eyes from the problem? And will build fail-safes around some of the obvious UB.

[notriddle]

Yes, this value will require infinite memory, but theoretically it’s a valid value, no?

If that’s true, then ! is inhabited. You just have to run an infinite loop to completion to construct it Though, actually, I’m not sure if a Box is allowed to own itself (allocate some memory, write that memory’s own address into it, then transmute). You sure can’t drop it, but you might be allowed to forget it.

So shouldn’t we properly specify ways to create uninhabited types as an improvement of Rust type system instead of averting eyes from the problem? And will build fail-safes around some of the obvious UB.

struct Endless<'a>(&'a mut Endless, &'a mut Endless);

Assuming we don’t allow an infinite graph, the pointers need to either form a loop or dangle. It can’t be dangling, because exclusive references are not allowed to dangle. It can’t be a loop, because that would mean both endless.0 and endless.1 form paths to endless, violating the no-aliasing rule of mut-references.

Do you want to bake that kind of complicated reasoning into the type system? Or do you want to have the type system treat it as an inhabited type, even though it isn’t?

[scottmcm]

Same goes for Vec<!> , I’ve asked several times, but no one have provided any practical examples of why such “pathological types” should be allowed.

Suppose you want to parse multiple things, and separate the parsed values and the errors. Something like this:

use std::str::FromStr;
pub fn parse_many<T: FromStr>(xs: &[&str]) -> (Vec<T>, Vec<T::Err>) {
    let mut successes = Vec::new();
    let mut errors = Vec::new();
    for x in xs {
        match x.parse() {
            Ok(v) => successes.push(v),
            Err(e) => errors.push(e),
        }
    }
    (successes, errors)
}

Well that uses Vec<Uninhabited> when T = String.

[felix.s]

Do you want to bake that kind of complicated reasoning into the type system? Or do you want to have the type system treat it as an inhabited type, even though it isn’t?

(Slightly off-topic idle question: wouldn’t it suffice for the compiler to assume the type is uninhabited unless it succeeds at proving otherwise by induction over type structure?)

[drXor]

Depends on how smart it has to be to prove that. For example, proving that every field of a struct is inhabited is insufficient, because of the &mut alias example.

[notriddle]

(Slightly off-topic idle question: wouldn’t it suffice for the compiler to assume the type is uninhabited unless it succeeds at proving otherwise by induction over type structure?)

You can’t replace Rust’s existing inhabitedness checker with one like that.

Right now, Rust allows you to use a match void {} to convert from uninhabited types to any other type. This has to be a conservative guess in the opposite direction: do not allow empty match unless void is definitely uninhabited, because empty match has the same type signature as transmute.

I guess that you could define it so that the Inhabited trait uses a different analysis than the match checker, but that would mean APIs that have an Inhabited bound might not work with types that the user is able to construct and use in normal live code. That sounds like a really complex “feature” that would hit like an unexpected slap in the face. You’d be stuck fighting the inhabitedness checker just like you currently fight the borrow checker.

[felix.s]

Depends on how smart it has to be to prove that. For example, proving that every field of a struct is inhabited is insufficient, because of the &mut alias example.

Not if you have to prove T is inhabited before establishing that &mut T is inhabited.

On the other hand though… it seems it’s perfectly possible to at least construct &mut Haskal with some dextrous use of unsafe, essentially just as @notriddle described:

unsafe {
    let mut val: Box<Haskal> = Box::new(mem::uninitialized());
    ptr::write(&mut val.0, mem::transmute::<*mut Haskal, Box<Haskal>>(&mut *val) );
    let valp: *mut Haskal = &mut *val;
    mem::forget(val);
    mem::transmute::<_, &mut Haskal>(valp)
};

Of course, this is a silly example, and its validity (not to mention usefulness) is questionable. But hey, it compiles on playground and behaves as expected (which is to say, it blows the stack when attempting to print it out).

Right now, Rust allows you to use a match void {} to convert from uninhabited types to any other type.

Uninhabited enums only, it seems. This fails to compile, even on nightly:

enum Null {}
struct Void(Null);

fn stare_into(void: Void) {
    match void {}
}

If you had in mind something like enum AmIInhabited<T> { X(T) }, I think it is already the case today that the type checker has to assume that any type parameter may be potentially used with an inhabited type, and so it cannot be assumed to be uninhabited.

[newpavlov]

Do you want to bake that kind of complicated reasoning into the type system? Or do you want to have the type system treat it as an inhabited type, even though it isn’t?

Ideally I would like to have smart compiler which will recognize type uninhabitness and will notify user. We could use an explicit #[uninhabited] attribute to silence the warning.

Can you provide other example of non-trivial uninhabited types (i.e. not empty enums or their composites) which are not recursive?

@scottmcm

Hm, good example. Although in practice I am not sure why user will use such approach instead of simply going with Vec<Result<T, T::Err>>, but nevertheless I can accept it as a motivation for allowing Vec<!>. (though I am personally still neutrally-negative about this feature)