Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk