Re: [boost] [optional] Safe optional

Subject: Re: [boost] [optional] Safe optional
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2014-11-18 00:08:43

On Mon, 17 Nov 2014 19:57:08 -0800, Vladimir Batov  
<Vladimir.Batov_at_[hidden]> wrote:

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

I'm in agreement with the last sentence. What I'm saying is that the  
current optional usage pattern, IMHO, is just too inconsistent.

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

And that exacerbates the problem doesn't it? If optional<T&> is just used  
5% of the time, then when that particular gotcha is hit, it'll be that  
much harder to diagnose the issue. Not all programmers are full time C++  
programmers, not all programmers develop new code full time, some do quite  
a bit of maintenance, so not everyone is going to be an expert in the ins  
and outs of any particular library. The simpler a library is to use, the  
simpler it will be to maintain the code which uses it.

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

Then why specify in the interface in the first place?

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

They will be competing libraries. But I don't see that as a bad thing. It  
will only be confusing if the rationale for their difference is not well  
documented.