RE: [boost] Re: Re: Variant implementation change (wasre:unions)finalsummary

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-10-09 18:07:50

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Rainer Deyke
> Sent: Thursday, October 09, 2003 5:37 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Re: Variant implementation change
> (wasre:unions)finalsummary
> 
> Brock Peabody wrote:
> > Yes, and the point I was trying to make with (5) really has nothing
> > to do with exceptions anyway.  Making it so that variants can be
> > singular
> > increases the complexity and chance for error in all code that uses
> > variants.
> 
> And my point is that having a singular state that can only be entered as a
> result of an exception in a variant function that only provides the basic
> exception guarantee is morally equivalent to not having a singular state
> at
> all.  Any code that relies on the value of the variant after such an
> exception has been thrown is broken anyways.

OK, on the face of it that does seem to be the best of both worlds.  Would
the invariant be that the variant contains one of {T0, T1, ... TN} except
after a failed assignment, in which case it is "empty"?

Would it be kosher for 'typical' visitors to ignore the possibility that the
variants they are visiting are the victims of failed assignments?

Anyway, I think this is a great solution.

Brock