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

Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-06-03 06:52:06

Le 02/06/2017 à 19:24, Peter Dimov via Boost a écrit :
> 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. :-)

Peter, I not be against an implementation that returns nullptr of 
operator-> as far as this is not documented and something the user could 
use.
If returning a nulptr is the best thing that we can do today in order to 
help the current tools to catch UB, why not.
I don't agree on documenting it, because this could make some user code 
more complex.
When you have a narrow contract you know that the check must be done 
before. If you document that it the user can be tempted to check it. 
Well operator-> is particular in some way as the user doesn't use to use 
it as x.operator->().
Consider for a moment that some compiler manage better UB when we do a 
check and assert for unreachable code (as other are suggesting). 
Requiring a nullptr as result will forbid this implementation, isn't it?

My question is, why do you consider that it is good to document it?

Vicente