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

On 15. Nov 2017, at 01:35, Niall Douglas via Boost 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?