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 :
> 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
> 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.
>>> 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 !!!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk