Boost logo

Boost :

Subject: Re: [boost] [variant2] Formal review
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2019-04-15 14:46:37


Emil Dotchevski wrote:
> If the design allows for one more state, then that state must be handled:
> various functions in the program must check "is the object empty" and
> define behavior for that case.

I think that's often not really the case; at least, it is not a large
burden.

It seems to me that in many/most cases, the empty state is essentially
transient; it can exist between the throw in the assignment and the
end of the variant's scope:

void f() {
  variant<...> v{42};
  v = something; // throw in assignment; v is empty
  foo(); // skipped
  blah(); // skipped
  // v is destructed
}

You can only observe the empty state if you have a try/catch inside the
scope of the variant. Or possibly something with a dtor that accesses
the variant. If you limit yourself to not doing that, then you can
ignore the possibility of empty in the rest of your logic.

What do others think? Do you believe that it would be common to
catch the exception thrown during the variant assignment and not
"fix up" the variant's value, such that code after the catch could
see the variant in its empty state?

Regards, Phil.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk