Re: delayed_forward: good, bad, ugly?

From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2023-01-10 13:56:39

> On 10. Jan 2023, at 12:16, Alexander Grund via Boost <boost_at_[hidden]> 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?