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

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

I created a DR which proposes the renaming as rsmith suggested: https://reviews.llvm.org/D103720

In D100733#2773944 <https://reviews.llvm.org/D100733#2773944>, @aaronpuchert wrote:

> 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.

Sure, I had it in mind that is not necessarily how that would be explained to the users, but perhaps as the standard text is more geared towards the toolchain folks, the original explanation might be more suited there, and this alternative one is more didactic, as you pointed out it can be explained just in the context of implicit moves.

> 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.)

Thanks. That makes sense!

In D100733#2773944 <https://reviews.llvm.org/D100733#2773944>, @aaronpuchert wrote:

> 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#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?

We might want to hold on to the second step there (adding back another isRValue) for a little while, to give time for people to rebase patches and such, so they get a friendlier build breakage instead of some more subtle issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100733