Re: [boost] Outcome/expected/etc/etc/etc

Subject: Re: [boost] Outcome/expected/etc/etc/etc
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2017-06-05 15:09:30

On Mon, Jun 5, 2017 at 10:39 AM, Peter Dimov via Boost
<boost_at_[hidden]> wrote:
> Gottlob Frege wrote:
>
>> So converting a Circle to a Triangle might result in a Rectangle, because
>> Rectangle is the fallback?
>
>
> If an exception is thrown, yes. That's how the basic guarantee works.
> "Converting" from a vector with 5 elements to a vector with three elements
> may result in a vector with zero elements on failure, and "converting" from
> a Circle to a Circle may result in a Circle that is neither of those two.
>
> I argued that variant's assignment should provide the strong guarantee, as
> the usual idiom of copy+swap that is used for other types doesn't work for
> variant, but was persuaded that it in fact does, in the final wording. I
> have to verify whether this holds in my implementation, and under what
> conditions.
>
>> I'd rather have double buffering or valueless_by_exception.  ie
>> correctness or acknowledgement of error.  Not silent incorrectness.
>
>
> It's your prerogative to be wrong. :-)
>

It just means I need to double buffer higher up.  I really want my
drawing program to just fail (rollback) the transaction if it can't
complete - that is what users really want.

And I then probably need a NoShape shape to be the default, instead of
Rectangle, so I can detect it.
And then I wonder why I switched to variant2.

>> Why not add "throw E if derived from std::exception" as part of that
>> fallback?  It is probably what users want.(?)
>
>
> This would imply that expected<> would be used to return types derived from
> std::exception, and I don't see this as common. Although with that said,
> yes, it would be easy to add that as part of the default behavior if there's
> demand for it.
>
> It would open the door to the subsequent question of whether it ought to be
> possible to override the behavior for a whole hierarchy rooted in a user
> class in a similar manner, though, which would imply that the default would
> need to be made a worse match in some way. There are pros and cons for that.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost