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.)