On 10/01/2023 07:15, Peter Dimov wrote:

If I understand correctly, the lack of strong guarantee is caused by the by-value constructor moving from the argument even when construction fails? E.g.

Foo foo( true, std::move( my_t ) ); // leaves my_t moved-from on exception

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

...

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

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

Alexander Grund wrote:

...

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.

Yes, however at the callsite you can clearly see the different semantics: "try_" That's much harder for a constructor. Although a well-named factory method might be a solution if this semantic is useful.

For a constructor example, see https://eel.is/c++draft/util.smartptr.shared.const#29.

Hans Dembinski wrote:

...

On 9. Jan 2023, at 19:15, Peter Dimov via Boost wrote:

It will be better if you show how the existing code (before the delayed_forward transformation) looks like.

I added FooOld, which corresponds to the unsafe design I want to replace. https://godbolt.org/z/15q9EqnfP

Thanks. I note that as written, FooOld actually has the same problem even if the argument is not taken by value. template <class T> struct FooOld2 { FooOld2(bool b, T const& targ) : t_(targ) { if (b) throw 1; } FooOld2(bool b, T&& targ = {}) : t_(std::move(targ)) { if (b) throw 1; } private: T t_; }; There might be a difference between passing by value or not, but for that, the exception would have to be thrown from a base or previous member initialization, and not the constructor body.

On 11/01/2023 22:35, Hans Dembinski wrote:

Yes, FooOld2 is also unsafe, but you can use a rollback guard to undo the move.

FooOld3(bool b, T&& targ = {}) : t_(std::move(targ)) { rollback r(targ, t_); // moves t_ back to targ if not deactivated if (b) throw 1; r.deactivate(); }

Note that a rollback implementation is still unsafe if the type in question has a noexcept(false) move constructor -- which, while unusual, is legal -- and might be more common than you think when it decays to use the copy constructor instead. (This can also be bad for performance, though only when throwing, so you likely don't care.) A common surprise is that copy-constructor-only types will still satisfy std::is_move_constructible_v, although typically not std::is_nothrow_move_constructible_v. (Which is one of the reasons why the "rule of five" exists now.) (You might ask why this is unsafe, since we only care about exceptions thrown in the constructor body -- if the initial parameter move/copy throws that's a different case, right? But consider that the initial parameter move/copy might succeed, the constructor body throws, and then the rollback move/copy also throws. This is especially likely if the constructor throw was a std::bad_alloc, but other cases are possible.) This isn't to say that the above is bad; but if you use it, don't forget to static_assert your assumptions (or provide alternative implementations).