On 30/05/2017 13:25, Peter Dimov via Boost wrote:
Niall Douglas wrote:
value() id wide operator*() is narrow.
Why? Just because optional made that mistake?
The motivation here is that in
if( o ) { o->this_(); o->that(); o->this_other_thing(); o->that_too();
o->almost_forgot(); }
there is needless replication of the check. This, as I already mentioned, stems from a desire to operate on the value inside 'o' directly, which is not my preferred style in result's case, where I'd prefer to extract it instead.
Oh I get that was the motivation, and that's exactly where I find the most objection with Optional: it has some pointer semantics, but it is not a pointer, and so shouldn't be pretending to be one. It not being a pointer should have always been made clear to end users (by forcing them type more boilerplate) to extract immediately or else bind a lvalue ref to the internally stored value. Don't treat not-a-pointer as a pointer. I also, weirdly enough given the discussion till now, really dislike the wide contracts anywhere on Optional. Unlike Expected or Outcome, the compiler can instantly tell if you're being stupid when using Optional. So I'd have chosen all narrow observers personally, and have the compiler error with obvious UB usage and warn if you observe an Optional returned by an extern function without checking its state first. But that ship has sailed sadly.
There is a middle ground here, which I was pondering for a while, make has_value return T* instead of bool.
It's a clever idea, but it reminds me too much of C++ 98 days of returning void * and such to implement boolean testing. We all got badly bitten with those tricks, for example if(std::cout) is not a compile error. *Shudder*. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/