Re: [boost] delayed_forward: good, bad, ugly?

On 10. Jan 2023, at 12:16, Alexander Grund via Boost wrote:

...

...

If so, that doesn't seem like an unusual feature -- https://clang.llvm.org/extra/clang-tidy/checks/modernize/pass-by-value.html strongly encourages that constructors accept movable values by value, which will always move-from them even if the constructor later throws. (If the parameter type's move/copy constructor throws then it gets more complicated, though move constructors at least are typically expected to not throw.) I'd also agree with that as I favor consistency. So after something `foo(std::move(bar))` I'd always assume that `bar` can no longer be used, I mean that's the point, isn't it? The `delayed_forward`, especially as hidden from the call site, voids my assumption: How would I know when exactly I can still use bar? I'd need to consult the documentation and address potential version differences for something fundamental.

So consistency here means: The target of a move operation is always a (data) sink. Not a "maybe-sink”.

That’s a fair point, which I did not really address in Gavin’s comment. Is this the consensus here?