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

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

...

You could also point to the actual code in Histogram for those who would like even more context.

Here is the related issue. https://github.com/boostorg/histogram/issues/379

The classes which we are discussing to improve are the axis classes. Several of these axis classes have throwing constructors. They all accept an optional Metadata in the ctor, which is user-defined and in general a non-trivial type. A comparably simple example is the integer axis.

https://github.com/boostorg/histogram/blob/develop/include/boost/histogra m/axis/integer.hpp

...

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

Yes. I added some code to main in godbolt to illustrate this.

I don't think I have any better ideas than what you did with delayed_forward. The irregularity of its operator(), where it sometimes assigns to the argument, and sometimes doesn't, isn't very elegant, but assigning a default-constructed value would be superfluous.