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.