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:31:37

Le 02/06/2017 à 02:43, Peter Dimov via Boost a écrit :
> Gavin Lambert wrote:
>> On 2/06/2017 00:15, Peter Dimov wrote:
>> > That's what I was thinking - that you want to place an assert there 
>> - I > just wanted to confirm that this is the only objection. Do we 
>> agree that > returning nullptr from operator-> is good for informing 
>> the static > analyzer and the optimizer that a value is present?
>>
>> I assume you meant "not present" there.
>
> No, I do mean "present". If you do `r->x` in your code, the compiler 
> from this point on will optimize based on the assumption that a value 
> was present - otherwise what you did would have been undefined.
>
> Actually, it will even propagate the "has_value()" assumption 
> backwards from the `r->x` point, not just forwards.
>
> Returning a reinterpret_cast'ed pointer, on the other hand, will not 
> do so, although maybe an `assert( has_value() )` will, depending. 
> (Last time I recall Microsoft tried feeding asserts to the optimizer, 
> they reverted it, as it broke too much code, but things may have 
> changed in the meantime.)

Peter, I now that we are designing a class in C++11/.../C++17. I want to 
know what do you think if we had contracts and that compilers (or static 
analysis tools) where smart enough to detect UB.
Would you expect that operator-> return a nullptr when there is no value?
Or you want it to return nullptr because you believe that this could 
help the current UB sanitizers or static analysis tools to detect some UB?

Best,
Vicente

P.S. Sorry fro the late responses; all you mails were considered as spams.