On Mon, Nov 17, 2014 at 12:24 PM, Andrzej Krzemienski
The solution is based on the observation that there is a limited number of things you can do with optional<T>
optional<int> oi = ...;
1: if (oi) doSomething(*oi); else doSomethingElse(); // or nothing
2: if (oi) doSomething(*oi); else doSomething(-1); // use default value
3: if (!oi) oi = (int)getIntByOtherMeans(); doSomething(*oi); // now it is safe
Now we simply provide a dedicated interface for each of these three usages:
1: oi.use(&doSomething, &doSomethingElse); // or use lambdas
I'd call it visit(). Also, a one argument visit() could be useful (the visitor would be passed boost::none if the value is absent).
2: doSomething(oi.value_or(-1));
We already have that.
3: doSomething(oi.value_or_eval(getIntByOtherMeans));
So, basically, the proposal is to add visitation API, am I correct? 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.
Regardless, if people come to an agreement on changes, I'm much more in favor of simply making breaking changes to the current optional rather than introducing another one. It's unfortunate for a type as fundamental and widely used as optional, but people will get over it, especially if it makes it closer to the standard proposal.
I would rather not go that way. boost::optional is not unsafe. It is simply something else than what some people think. Its conceptual model is more like any value of T, plus one additional value. In this model implicit conversions make perfect sense and are n fact desirable.
Exactly. Vladimir's example is an illustration of this.