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
> 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
>> 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:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk