Subject: Re: [boost] [variant2] Andrzej's review -- design
From: Gavin Lambert (boost_at_[hidden])
Date: 2019-04-04 23:29:41
On 5/04/2019 08:12, Emil Dotchevski wrote:
> But what's the upside? Why is the empty state preferable to another, valid
> state? Either way we must define behavior, but in the latter case the
> behavior is already defined, there is nothing to do.
The empty state is preferable to another unspecified state exactly
*because* it is obviously different, and thus is guaranteed to be
detectable (and will result in exceptions when accessed inappropriately,
or executing an intended-no-value-here evaluation path if one is provided).
The problem with transitioning to an otherwise valid but unexpected
state is that it may end up evaluating unintended code (oh, this variant
contains type B, let's do some standard type B handling -- oh but wait,
this wasn't the B that we had set ten functions ago, this is some
different B, because an assignment to A failed). This is a source of bugs.
(Granted, continuing evaluation on a faulted variable is already a bug
in itself, but you are making detection of that bug harder by not
putting the value into an obviously-faulted state.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk