Re: delayed_forward: good, bad, ugly?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2023-01-10 18:58:19

Hans Dembinski wrote:
> > On 9. Jan 2023, at 19:15, Peter Dimov via Boost <boost_at_[hidden]>
> 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.