Subject: Re: [boost] [optional] Safe optional
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-11-18 18:52:45
Le 18/11/14 22:35, Vladimir Batov a écrit :
> Andrzej,
>
> On 11/18/2014 08:23 PM, Andrzej Krzemienski wrote:
>> ...
>> And to remove operator* and get() and value() and get_pointer() -
>> anything that could cause UB. And remove implicit conversion from T
>
> 1. I might be open to the idea of unifying/cleaning the access
> interface and settling on one... but taking them *all* out?.. Or you
> want to keep operator->()? Then, I still can do
>
> optional<T> ot;
> T* t = ot.operator->();
>
> You might say, it's crazy. My point is that if you want to save me
> (the user) from myself with "safe optional", you are most likely
> wasting your effort -- an uneducated idiot will always find a way to
> hurt himself.
>
IIUC the goal of a safe_optional is to give access to the underlying
value only via functions/lambdas. I see it as a black box. Of course,
conversion from safe_optional<T> to optional<T> and vice-versa are IMO
mandatory,
> 2. I find it troubling that you keep bringing "remove implicit
> conversion from T " up. That indicates that the property is close to
> the top of your "grievances" list. On my side, I find that implicit
> conversion essential for sane interactions of users with "optional".
> Back a while, when we were discussing "optional" (was it ISO forum?),
> I remember Fernando Cacciola expressing the same opinion (and as
> strongly). I'd greatly appreciate if you could please provide
> practical usage/deployment examples where implicit conversion from T
> causes a problem.
>
It is about the pre-conditions. Before doing a conversion you need to
ensure that there is a value. This give an if-the-else style that
doesn't scale when you have several optionals in the game.
>
>>> In
>>> that case why not add it to the regular optional?
>>>
>>> IMHO, in order to introduce an alternative component, there should be
>>> significant and incompatible design and interface differences between
>>> the two. So far I don't see the need for such differences.
>>>
>> As explained above: serious backwards incompatibility. Unacceptable by
>> many, including myself.
>>
>
> I have to admit I find it somewhat of a concern hearing from the
> "optional" maintainer and someone leading "optional" for
> standardization that he does not seem to share/agree with the current
> "optional" design to the point where you are keen on forking a
> "seriously incompatible" variant. Going ahead with the latter will be
> a lot of effort implementing, promoting, educating, defending... IMO
> that'll be the effort 1) not necessarily successful; 2) fragmenting
> the user-base; 3) most importantly, it'll be the effort taken *away*
> from the current "optional"... which seems so close (hopefully) to
> standardization. If you have concerns (you would not initiate the
> conversation if you did not), let's discuss them within the "optional"
> boundaries and document/justify the decisions made. Do I worry too much?
>
Things are moving in C++ to the functional paradigm very quick. People
would need to learn, soon or late, functional programming and monads.
I'm sorry, they are viral !!!
Best,
Vicente