Subject: Re: [boost] [optional] Safe optional
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2014-11-17 19:25:28
On Mon, 17 Nov 2014 13:12:56 -0800, Vladimir Batov
<Vladimir.Batov_at_[hidden]> wrote:
> 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.
Just to clarify, since the discussion is in the context of an "alternative
optional", what I wrote about how the existing library should behave just
applies to the alternative one.
> 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?
Not all classes have gotchas. And, IMO, C++ has too many gotchas as it is.
> 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.
>
> However, implicit T to optional<T> conversion has a very practical
> purpose.
And that leads to the intractable rebinding gotcha for optional<T&>.
> 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>
> Instead, asking the user to call explicitly
>
> value(optional<22>)
>
> is a professional suicide.
Templates are neither new nor unknown in C++. If you find yourself typing
too much, just use a typedef.
> 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.
If there are multiple valid yet incompatible design choices, then IMO
there is nothing wrong with providing alternatives.