Re: [boost] [outcome] To variant, or not to variant?

Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Peter Dimov (lists_at_[hidden])
Date: 2017-06-02 17:24:42

Andrzej Krzemienski wrote:

> > Not merely potential. Actual slowdown on the order of 100. You should 
> > read it as "as much as we'd like to define the behavior of operator[], 
> > doing so would be prohibitively expensive, so we won't."
>
> Why the same argument with "compiler will see that I am checking the same 
> condition twice, and remove redundant checks" does not apply here?

Because we can test it and see that it doesn't. This is an empirical 
argument, not a theoretical argument. "But it's the same here!" Well no, it 
isn't, we can measure it.

> > We have no tradition in expressing the above, so within the current 
> > vocabulary I prefer guaranteeing the `nullptr` instead of leaving the 
> > behavior undefined in the hope that it will end up being defined to the 
> > above. (It won't be.)
>
> That is true, "it wont' be". And that was never the goal.
>
> But what is the gain with the nullptr trick? someone can still cause UB 
> with it, so it does not seem much "safer". Are you increasing the chances 
> that it will be trapped by the operating system?

It's again a practical argument - we know what it does. In principle, it 
should be the same, but it isn't. We know that if we write the specification 
this way, so and so happens, and if we write it another way, different 
things occur. :-)