Re: [boost] [operators] A modern SFINAE-based version of boost::operators?

Subject: Re: [boost] [operators] A modern SFINAE-based version of boost::operators?
From: Daniel Frey (d.frey_at_[hidden])
Date: 2017-11-15 15:27:44

> On 15. Nov 2017, at 01:35, Niall Douglas via Boost <boost_at_[hidden]> wrote:
> 
>> If you pass in an rvalue reference, you *do* expect it to be modified and you do not expect it to be accessible afterwards.
> 
> That's only an until-so-far STL convention.
> 
> In my own code I treat rvalue references as "this may or may not be
> consumed" parameter. So the function may consume the input wholly,
> leaving it in some zombie state. Or it may leave it as is. Obviously the
> return type says what happened.

OK, I should have said you do have to expect that the value might be modified. But in the general case, you won't know if any function taking an rvalue-reference will or will not modify / move it. Only if it is explicitly documented (or if you have control over it), you can know. And documentation is not checked by the compiler.

> This lets you write filtering functions such as:
> 
> SomeObj foo.
> filter_a(std::move(foo));
> filter_b(std::move(foo));
> filter_c(std::move(foo));
> filter_d(std::move(foo));

For this example this might work, but you can not use this kind of thinking in general or force it on anyone.

> In case anyone thinks I am being weird on this, I was taught to think of
> rvalue ref parameter inputs this way by Howard Hinnant. It's been a
> useful technique to know. I just wish clang-tidy didn't warn on this
> technique so readily.

I wonder why you don't just pass in a lvalue-reference. You can still modify the value in one of those functions and the remaining state should be visible to the following functions just like before, no?