[expr.unary.op] Fix usage of "result" #3945
Conversation
|
Why exactly is a fix necessary here? [basic.lval] defines "result" of a glvalue and result of a prvalue, but the usage here seems to be "result of an operator". |
I find this confusing. Result is the object to which the lvalue refers. And the type of the result is the type of the object, which is not necessarily the same as the type of the lvalue. |
|
Ah, dynamic type vs. static type. It seems we need a clearer dictionary to talk about the static type of an operand / the result of the operation vs. the (dynamic) type of the result. Talking about "static" and "dynamic" type has its own set of ugliness, so what words should be in that dictionary? Once we have that clarified, we should fix all of [expr] to do the right thing. What do you think about my reformulation? |
languagelawyer
force-pushed
the
expr.unary.op
branch
from
7789423
to
da96210
Compare
I've used it, but changed the "The lvalue result ..." part. |
zygoloid
added
the
changes requested
languagelawyer
force-pushed
the
expr.unary.op
branch
from
da96210
to
c55fc9d
Compare
jensmaurer
removed
the
changes requested
|
Will take a look. |
| referring to the object or function to which the expression points. If | ||
| the type of the expression is ``pointer to \tcode{T}'', the type of the | ||
| result is ``\tcode{T}''. | ||
| Its operand shall be a prvalue of type ``pointer to \tcode{T}'', |
There was a problem hiding this comment.
@jensmaurer: is it a normative change to require that the operand be a prvalue, or was that previously implied by other wording?
There was a problem hiding this comment.
The descriptions of most operators are unclear whether their operands are prvalues or lvalues.
Anyway, for the dereferencing operator, it's pelucidly clear that it takes a prvalue, always. Maybe the prior text saying "shall be a pointer to an object" could be interpreted as "shall be a pointer value...:", meaning a prvalue of pointer type.
There was a problem hiding this comment.
I suppose this is largely inherited from C, where things aren't lvalues unless they're explicitly called out as lvalues.
The normative impact/question is whether there's an lvalue-to-rvalue conversion in something like *p. I agree that this can't really be anything else (after all, you need to "load" the pointer value before you can dereference it), but it just feels a tiny bit bold to establish such clarity editorially. Let's proceed optimistically, but let CWG know via email.
There was a problem hiding this comment.
@languagelawyer: thank you!
|
@jensmaurer I think we can take this, but I would appreciate if you took a final fresh core look at this and confirm that this is both correct and an improvement. |
|
I think I want to have a CWG look at this, just to be on the safe side. |
|
Approved by CWG telecon 2022-08-26. |
|
@jensmaurer Just to confirm, we can remove the |
|
Removed "cwg" label. |
Do paragraphs 7-10 need similar fix or we fine with «the type of the result is
X» when it means the type of the resulting prvalue?