Re: [boost] [optional] Safe optional

Le 17/11/14 17:41, Matt Calabrese a écrit :

On Nov 17, 2014 1:25 AM, "Andrzej Krzemienski" wrote:

...

No, no exceptions. 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

2: doSomething(oi.value_or(-1));

3: doSomething(oi.value_or_eval(getIntByOtherMeans)); While I agree that we should be encouraging high order functions/visitation here, my personal experience is simply that many people do not like it. When given the choice to pass a lamda or to use an "if" or a range-based-for over high order function alternatives, programmers will generally opt for not using a lambda. The fact that Bjarne thinks visitation is somehow "bad" doesn't help. I agree that it's safer and I'd be in favor of it, but be aware that not everyone will like it. I will ad that I believe Dr BS don't like dynamic visitation, but here we are doing pattern matching on types, isn't it?

That said, I'd be in favor of this. If going with this approach, though, I'd say make optional a model of a variant and/or discriminated union concept that it and variant share, along with "expected" if it were to make it into boost (I.E. allow for apply_visitor of T and none, provide a "which"). I'd still like to see the other functions you mention as well for convenience.

Yes, all these types a sum types, so any feature in the scope of sum types can be applied to all of them. In addition, one of the optional sum types is a non-a-value, and there is a lot of common thing for such types probably valued types. expected shares a lot with optional, but it in not the only one e.g. T*. The current problem we have with our TBoost.Expected is that we don't have an implementation for C++98 compilers :( If the Boost community can accept a C++11 only library I'll be glad to work on preparing it for review. Is there any one that wants to work on a branch to port it to C++98 compilers?

I know that there are others (Eric?) who prefer to think of optional as a container of size 0 or 1, so it could also make sense to provide an accessor to a range. One interesting effect of this is that now range-based-for sort of becomes a "visit if." There are probably other... interesting uses of standard algorithms.

...

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. I'm not sure I agree. These two templates aren't exactly complimentary in terms of the functionality that they provide, they really would just provide exactly the same functionality with the same internals. All that is different is the interface. Because of that, I say either it replaces optional or it doesn't exit as a part of boost. If people are convinced that this interface is less error prone, then it should be THE interface for optional.

Andrzej, I think I see what you meant by a safe_optional. A safe optional wouldn't provide direct access to the value. (Sorry I need sometime to understand things). Couldn't safe_optional just be a wrapper of optional restricting its interface? safe_optional could be explicitly convertible to optional and optional implicitly convertible to safe_optional. Instead of safe_optional I would prefer to don't use the safe_ prefix, as optional is safe already. IIUC, safe_optional is limited to a monad interface and whatever we can build on top of it. What about monad_optional<T> or monad::optional<T>? @Matt I don't think we need to choose instead of the user. We have here two complementary interface to the same data, there is no one better than the other. Up to the user to choose the one more adapted to his needs. Best, Vicente