Re: delayed_forward: good, bad, ugly?

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2023-01-10 11:16:55

>> 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".

Alex