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