clarify UB for raw ptr deref

[RalfJung]

Following discussions on Zulip

[danielhenrymantilla]

Mentioning / linking to an actual distinction between value and place expression seems totally reasonable when talking about pointer dereference (especially if the rules ended up loosened for to-place-dereferences), so 💯 from me! ✅

[danielhenrymantilla]

I think this was raised in the Zulip conversation, but I'll nevertheless raise it here: I wonder if a word other than e-valu-ating could be used when talking about a place expression (although I couldn't come up with one satisfactory enough, so feel free to disregard this nit).

[RalfJung]

Clearly the right term is "placating".

On a more serious note, this is one reason why I argued fiercly against calling these things "values"/"value expressions", but I was unable to convince enough people to make a difference...

[Havvy]

This feels weird to me, because a dereference is always a place expression.

[RalfJung]

Well, it can be used as a value expression as in

let x = *expr;

Arguably, here it is correct to say that *expr is (used as) a value expression.

[Havvy]

We call that a "value expression context" (and "place expression context" for where a place is wanted). Is it only UB to evaluate an unaligned/dangling pointer in place expression context, or always?

[RalfJung]

"value expression contexts" are a superset of "place expression contexts". IOW, the code above is sugar for

let x = place2value(*expr);

Evaluating a place expression in value expression context consists of first evaluating the place expression as normal, as then performing place-to-value conversion.

So, it is impossible to write *expr anywhere without it being also a place expression, but sometimes, it is both a place expression and a value expression (or really, place2value(*expr) is the value expression, but since we have no syntax for this, people tend to say that *expr is [used as] a value expression).

That's the way I am thinking about this, anyway.

So, the answer is that it is always UB to evaluate an unaligned/dangling *expr since doing so always evaluates the place expression -- and then sometimes goes on performing place-to-value conversion. The important point that I hope to clarify in the docs is that it is the place expression evaluation, and not the place-to-value conversion, that is causing the UB.

[Havvy]

"value expression contexts" are a superset of "place expression contexts"

We have a difference of perspectives here; these two categories are distinct and split the set of expression contexts. A place expression in value expression context is allowed and has the place2value effect, but it's still always a place expression.

So, under my perspective, the [place expression] should be , even in [place expression contexts],.

---

Evaluating a place expression in value expression context consists of first evaluating the place expression as normal, as then performing place-to-value conversion.

I like this sentence. I think I'll try and get it into the PR I submitted last night (#1003 )

[RalfJung]

So, more like this?

@digama0 I'd be interested in your opinion here, is this current wording sufficiently clear? (I know you'd like the rules to be more relaxed; so do I. That is a longer process. For now the goal is to make sure that the rules as they currently are are described unambiguously.)

[digama0]

LGTM

[Havvy]

💟 Thanks!