Re: [boost] [optional] Safe optional

Subject: Re: [boost] [optional] Safe optional
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-11-17 22:57:08

On 11/18/2014 11:25 AM, Mostafa wrote:
> 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>
>>>
...
>> 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.

Well, that's far too broad a statement to be argued over... still, my 
logic behind restrictions-related statement is that, say, a class 
provides a service, nothing is free, so to make use of the service the 
user needs to give something back... be that adhering to certain 
deployment pattern or API or something.

>
>> 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&>.

Yes, I've heard of that "beast". In all honesty to me it looks quite 
esoteric and beyond the realm of practical every-day programming. I 
suspect if it's taken out altogether, 95% of the users will not even 
notice. I can be wrong though and prepared to be convinced otherwise... 
if you show me a practical example where it's a must-have... Without 
such I fully understand/support the decision to get rid of optional<T&> 
for std::tr2::optional proposal. So, re-phrasing J. Stalin's "no man, no 
problem" -- "no "feature", no problem.

>
>> 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.

Hmm, not sure I follow what templates have to do with it... and the 
amount of typing is irrelevant. The point was if conceptually user 
expects to use/deal with "int", then the requirement to explicitly 
specify optional<int> looks unreasonably heavy and unnatural. It exposes 
too much underlying infrastructure where it does not need to. All IMO of 
course.

>
>> 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.

I do not believe it's that simple. If, when referring to "incompatible 
design choices", we are talking about differences like "car vs. truck", 
then I'd argue that those are not alternatives as they serve quite 
distinct purposes and, therefore, adhere to different designs. 
Otherwise, having "incompatible design choices" like a toothbrush and a 
"safe" toothbrush and a "whistling" toothbrush are distracting and 
confusing and IMO counter-productive. I had an impression that "safe" 
optional suggestion was more in the latter camp as it still very much 
wanted to be "optional"... but a tiny bit different. It  might well be 
that I misunderstood.