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.