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, gregod at, cpdaniel at, john at