Re: [boost] [optional] Safe optional

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

On 11/19/2014 07:37 PM, Andrzej Krzemienski wrote:
> ...
> Ok, this concern deserves a clarification from my part. I am more than
> satisfied with the current design of both boost::optional and
> std::optional. i find the decisions right. The direct (unchecked) access to
> the contained value is essential. The conversion from T may not be
> critically essential but is very useful. My motivation is NOT the
> dissatisfaction with the current interface.
>
> You are right that by starting this thread I might have been sending the
> opposite message. Therefore I am declaring my position and motivation here
> explicitly.
>
> It is simply that I observe and acknowledge the expectations of a portion
> of the community to have a different interface.

People will have different expectations no matter what. You provide 2 
interfaces then there'll be a group wanting third. If satisfying that 
"special community" is *truly* the driving force behind your alternative 
initiative, then it's ill-conceived IMO as it sends the wrong message to 
the "main community", sends the wrong message to the standardization 
committee, fragments the user-base... you see the picture.

Instead, I'd see documentation of the design and deployment patterns, 
education to be the right way to go... unless you are in that "other 
community"... that's when alarm bells start ringing for me with regard 
to the current "optional".

> I also acknowledge that
> having two interfaces for nearly the same thing may be a bad idea in
> itself. This is why I am simply discussing (talking) and not taking any
> actions. I want to hear others' input. And I find yours particularly
> valuable.
>
> Note that the interface I am proposing is not just fool-proof. It is
> designed in a way that forces you to express your intentions rather that
> just giving orders. The safety is not achieved by just prohibiting things
> but by forcing you to rethink what you are doing.
>
> To some extent, I consider Boost an incubator of ideas rather than "the
> standard way of doing things".
  I have to disagree. IMO Boost has outgrown that phase long ago and as 
it is *now* to the programming community at large Boost is not an 
incubator. It's THE "almost standard" extension of the Std. library. 
Consequently, one needs to think twice offering something as confusing 
as an incompatible alternative to something as fundamental and 
entrenched and ready for standardization as "optional". If it was 
something spanking new and unknown, it might be very different.

> I would agree that having two optionals in
> STD would be a bad message. This is less so for Boost. We would have people
> experiment with an alternative and decide which they find better, and they
> could deliver their opinion to the Standardization committee.

I suspect the committee does not need/want  those 2 opinions. They need 
a solid library with established user-base... nothing less... I can't 
speak for them though and can be easily wrong.

> ...
> optional<double> Aircraft::weight()
> {
>    if (Impl* impl = get_impl())
>      return impl->compute_weight();
>    else
>      return none;
> }
>
> double Aircraft::max_weight()
> {
>    return 10000.0;
> }
>
> bool too_heavy(Aircraft& ac)
> {
>    return ac.weight() > ac.max_weight();
>    // in "safe" optional compiler would spot the bug
> }

There is no bug here! Not from the human perspectives. You are comparing 
two extremely closely related types! As long as we agree on how "none" 
is treated, then all kosher. We do compare "ints" with "doubles", don't 
we? No "safety" concerns.

> This example only tells me that there exist some use cases where conversion
> from T is dangerous/unintended/surprising. I DO NOT conclude that it should
> have never been added.

This only tells me :-) that you seem to suffer from a common s/w 
programmer syndrome -- you are thinking as a machine rather than a 
human. Pls do not get me wrong. It's not an insult. I catch myself doing 
the same and have to force myself to step back and think as a human :-) 
and code for human rather than for a machine. I hope you see what I mean.