"_" patterns and validity invariants

[RalfJung]

The following code is not even unsafe, so it certainly cannot be UB:

fn foo(ptr: *const bool) {
    let _ = *ptr;
}

foo(&3u8 as *const u8 as *const bool);

This indicates that the pointer does not really get dereferenced, so the pointed-to data is never interpreted at type bool and thus must not be valid. I am not sure I like this; *ptr (as a value expression!) to me seems like it should conceptually perform the load even if the result is later discarded.

Something similar happens here:

fn bar(ptr: *const (i8, bool)) { unsafe {
    let (x, _) = *ptr;
} }

This compiles effectively to let x = (*ptr).0, so again whatever data is in the second field does not matter. (Note that *ptr here occurs only as a place expression, not as a value expression, so it makes sense that in (*ptr).0 we do not require the second field to be valid.)

I think this behavior of "_" can be explained by saying that it suppresses the place-to-value coercion, and it is smart enough to even do this in cases like (x, _) where the coercion is partially suppressed. But I am not sure I like this semantics, it seems rather counter-intuitive to me. It also makes patterns much harder to explain. And it leads to strange special cases such as rust-lang/rust#79735 (I cannot tell if this is some compiler author also being confused by "_", or if the intention is that ! is special in that even creating the place is already UB, or something else).

[RalfJung]

@Nadrieril points out that

Right now you are allowed to write let (y, _) = x if we moved out x.1 already. The corresponding match is not allowed tho

[RalfJung]

The corresponding case for partial initialization can currently not be probed since rustc no longer permits writing to individual fields of a not-yet-initialized struct:

fn main() {
    let x: (i32, bool);
    x.0 = 5; // this already errors here...
    let (y, _) = x; // ... so we cannot test if this would be accepted
}

If this code was accepted, that would be further evidence for _ patterns inhibiting place-to-value coercions.

[RustyYato]

Like this?

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3d2143d5f263fb1a6d324c65feb0dc31

fn main() {
    let x = (0, String::new());
    drop(x.1);
    let (x, _) = x;
    // let (x, y) = x; // doesn't compile
}

[RalfJung]

drop doesn't change the content of the location though, the value still adheres to the validity invariant (and it has to, otherwise ManuallyDrop would be unsound).

[scottmcm]

The following code is not even unsafe, so it certainly cannot be UB:

It was unsafe back in <=1.21, though. Is it not-unsafe on purpose, or by accident in the MIR unsafety check?

[tmiasko]

The MIR for let _ = *p; is empty, so it could well be accidental.

[elichai]

This is IMHO even more confusing because let _ = a; doesn't even drop a, so it feels to me like let _ = $expr doesn't discard the expression so the read should actually read.
(on the other hand you could argue that this is because $expr is just removed from MIR, and then it won't drop + it won't read, but that feels less intuitive for someone who doesn't think about IR when writing code)

[RalfJung]

let _ = a; doesn't even drop a

Well, it drops a sometimes...

fn mark() {}

fn test1(x: Vec<i32>) {
    let _ = x; // nothing happens here
    mark();
}

fn test2(x: Vec<i32>) {
    let _ = vec![1]; // this is dropped here
    mark();
}

[bjorn3]

In test2, it isn't the _ that drops it. It is the fact that the temporary vec![1] goes out of scope that drops it.

[RalfJung]

Well, but the _ is what makes it "go out of scope", so I don't think one can entirely separate these two things.

One could just as well argue that let _ = x in test1 makes "x go out of scope".

[gThorondorsen]

One could just as well argue that let _ = x in test1 makes "x go out of scope".

Currently, it does not. But it does in this very similar test using let _ = {x}; instead.

[RalfJung]

Currently, it does not.

Yeah, it doesn't, but by analogy with let _ = vec![1];, maybe it should.

The current situation seems mostly consistent (except for rust-lang/rust#79735), but it's strange because behavior heavily depends on whether the expression on the right evaluate to a temporary or an existing place.