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