2014-11-18 7:59 GMT+01:00 Vicente J. Botet Escriba : 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>? I agree with these suggestions. I do not want to explore the possibilities
in detail just yet. As the first step, I want to check if there exists
consensus on having two types like this, offering different trade-offs. @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 _______________________________________________
Unsubscribe & other changes: http://lists.boost.org/
mailman/listinfo.cgi/boost