PiotrZSL added a comment.
In D141569#4163607 <https://reviews.llvm.org/D141569#4163607>, @ccotter wrote:
> bump. I never heard back on the case where using an rvalue reference for a
> big pod type as opposed to const ref.
I have such use cases in project, they not necessary POD, but more like a way
to wrap many arguments into single class.
Something like this:
struct A
{
void call();
};
struct Parameters
{
A subclass;
// here bunch of other members
};
void function(Parameters&& p)
{
p.subclass.call();
}
void test()
{
A a;
function({a});
}
When you change this into normal lvalue reference, then it wont compile, when
you add const then it also wont compile.
In this cases I would probably used //NOLINT, so don't consider this case for
this check as blocker.
For POD this issue also may happen but it's related more to the scenario when
function modify input data by exploiting fact that input is not const.
In such case you may for example prepare message that would be created by using
{}, then call function that would take it as rvalue, function could fill up
some additional data like translation id, and send it.
By using rvalue you telling that function that it is an owner of this object
now and can do anything with it, including changing it, but not necessarily
need to move it.
But still this is also probably use case for NOLINT.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D141569/new/
https://reviews.llvm.org/D141569
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
