Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[basic.lval] Xvalue don't always denote entities whose resources can be reused #3951

Closed
wants to merge 1 commit into from

Conversation

sdkrystian
Copy link
Contributor

@sdkrystian sdkrystian commented Apr 20, 2020

Entities denoted by an xvalue can't always have their resources reused (i.e. inaccessible members, cv-qualification, etc.), and such entities generally have no guarantee as to when their lifetime will end. It's best we make this wording non-normative, and instead just say they are glvalue that denote objects/bit-fields and are not lvalues.

While this definition might sound circular, the value category of an expression is determined from the context in which it appears, not from the definition of what the value categories are.

Comment on lines +146 to 150
\item An \defn{xvalue} is a glvalue that denotes an object or bit-field and is not an lvalue.
\begin{note}
Such expressions typically denote entities near the end of their lifetime whose resources can be reused.
\end{note}
\item An \defn{lvalue} is a glvalue that is not an xvalue.
Copy link
Member

@zygoloid zygoloid Oct 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is really a reasonable pair of definitions any more, due to the circularity. I agree the old definition of "xvalue" was also not really a definition, but I'm not convinced this is an improvement. Perhaps we could arrange this more like "A glvalue is either an lvalue or an xvalue; lvalues typically refer to this kind of thing and xvalues typically refer to that kind of thing", but we should make sure we don't lose the "no function xvalues" property. But I don't have a good suggestion, so I'm leaning towards leaving this as-is, even though the existing wording is muddying semantics with intent.

@tkoeppe
Copy link
Contributor

tkoeppe commented Dec 14, 2020

Please reopen this if you'd like to continue the discussion or have new suggestions.

@tkoeppe tkoeppe closed this Dec 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants