Re: [boost] [optional] Safe optional

Subject: Re: [boost] [optional] Safe optional
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-11-18 02:11:44

Le 17/11/14 22:12, Vladimir Batov a écrit :
> On 11/17/2014 09:12 PM, Mostafa wrote:
>> On Sun, 16 Nov 2014 23:04:43 -0800, Andrzej Krzemienski 
>> <akrzemi1_at_[hidden]> wrote:
>>
>>> Hi Everyone,
>>> I would like to run an idea through everyone in this list. There is a
>>> recurring complaint about Boost.Optional that it allows you to do 
>>> "unsafe"
>>> things:
>>> 1. Inadvertent mixed comparisons between T and optional<T>
>>> 2. Unintended conversion from T to optional<T>
>>
>> The problem with optional is that it tries to be a drop-in 
>> replacement proxy for its underlying type, and, unfortunately, it 
>> can't fully do that. So it ends up with an identity crisis. IMO, 
>> optional should be treated as a first class object, not a thin 
>> wrapper around T, that means no implicit conversions to/from T, no 
>> implicit comparisons with T, etc... Last time I looked at this, that 
>> will solve the reference rebinding gotcha. That is, you'll have one 
>> behavior for optional<T> and optional<T&>....
>
> 1. With all due respect I do not feel I can agree with the above... 
> and I do not believe "optional" has a "problem"... especially of the 
> described magnitude. IMO the result of applying the conceptual/design 
> changes described above to the existing "optional" won't be "optional" 
> as we know it... not even close. And after using "optional" quite a 
> bit I can say I personally won't be very happy. IMO "optional" has 
> been born as a practical solution to a real problem and IMO it solves 
> it quite well. Yes, it has certain behavior that the user needs to be 
> aware of... but what class does not impose restrictions of that kind? 
> Any potential functional/behavioral change has to be looked at 
> individually.
>
> For example, I do agree that that there should not be implicit 
> optional<T> to T conversion. I was not even aware there was such.
This conversion must be explicit if any.
>
> However, implicit T to optional<T> conversion has a very practical 
> purpose. For example,
>
>     int value(optional<int> =optional<int>());
>
> allows me to shrink the API as value getter and setter are merged into 
> one function. Namely,
>
>     int k = value(); // Get the value
>     value(22); // Set the value. Implicit conversion of T to optional<T>
>
Please don't do that. Use just overload.
> Instead, asking the user to call explicitly
>
>     value(optional<22>)
>
> is a professional suicide.
>
> 2. As for the separate/additional "safe" optional, I am personally not 
> that thrilled by the idea as of now. IMO that'll result in user-base 
> fragmentation, incompatibilities and inevitably more confusion in the 
> end.
Anything useful for safe_optional is useful for optional. So I see 
safe_optional as a view of a restricted interface.
This doesn't mean that conversions from one to the other are not possible.

Vicente