Re: delayed_forward: good, bad, ugly?

From: Marshall Clow (mclow.lists_at_[hidden])
Date: 2023-01-10 14:04:16

On Jan 10, 2023, at 3:16 AM, 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”.See std::

See `std::map::try_emplace(k, args…)`.

https://en.cppreference.com/w/cpp/container/map/try_emplace

Notes:
        Unlike insert or emplace, these functions do not move from rvalue arguments if the insertion does not happen. 

— Marshall