[PATCH] D100733: [clang] NFC: change uses of `Expr->getValueKind` into `is?Value`

[Aaron Puchert via Phabricator via cfe-commits]

aaronpuchert added a comment.

In D100733#2760890 <https://reviews.llvm.org/D100733#2760890>, @mizvekov wrote:

> - I still think a new value category is simpler than the two phase overload resolution it replaces :D

Not sure if it's simpler, but it'll produce less confusing results.

> - This new value category would (so far as this is only an experiment I am running), only apply to standards older than c++23, where from then on it's just the current categories and the rules as in P2266 <https://reviews.llvm.org/P2266>.
> - Even in the old standards it replaces, it does not introduce any drastic changes. This new category is the same as XValues as far as overload resolution is concerned (with the small addition that it binds less preferentially to non-const l-value references), and as far as type deduction goes, it behaves exactly as LValues.

A new value category feels like a global change for a local problem. We can explain the behavior that we want without introducing a new value category: either as a “combined” overload resolution for xvalue and lvalue, where all candidates for the xvalue are strictly better than any candidate for the lvalue, or as a two-phase resolution that falls back only if there are no candidates. These explanations are equivalent.

In D100733#2761031 <https://reviews.llvm.org/D100733#2761031>, @rsmith wrote:

> What do we think about renaming `isRValue()` to `isPRValue()` and renaming `VK_RValue` to `VK_PRValue`, adding a "real" `isRValue()`, and then performing this cleanup?

One problem might be that C and C++ have different terminology, right? I like the idea of going with prvalue instead of rvalue, then it's the right thing for C++ and if you're coming from the C world it's at least not confusing. But perhaps I would not introduce for now an `isRValue` function. (Although C doesn't have xvalues, so maybe it doesn't matter?)

In D100733#2761052 <https://reviews.llvm.org/D100733#2761052>, @mizvekov wrote:

> Is there any special reason we ended up in this state of affairs with the swapped out names?

My impression is that some people didn't like the changes that came with C++11 and that it made the terminology of C and C++ somewhat inconsistent. (Though I think you can work with the C++ terminology in C, there are just no xvalues, but you can't work the other way around.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100733/new/

https://reviews.llvm.org/D100733