Subject: Re: [boost] [optional] Safe optional
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2014-11-18 04:21:09
2014-11-18 7:59 GMT+01:00 Vicente J. Botet Escriba <vicente.botet_at_[hidden]
> Le 17/11/14 17:41, Matt Calabrese a Ã©crit :
> On Nov 17, 2014 1:25 AM, "Andrzej Krzemienski" <akrzemi1_at_[hidden]>
>>> No, no exceptions.
>>> The solution is based on the observation that there is a limited number
>>> things you can do with optional<T>
>>> optional<int> oi = ...;
>>> if (oi) doSomething(*oi);
>>> else doSomethingElse(); // or nothing
>>> if (oi) doSomething(*oi);
>>> else doSomething(-1); // use default value
>>> if (!oi) oi = (int)getIntByOtherMeans();
>>> doSomething(*oi); // now it is safe
>>> Now we simply provide a dedicated interface for each of these three
>>> oi.use(&doSomething, &doSomethingElse); // or use lambdas
>> While I agree that we should be encouraging high order
>> 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
>> 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
> 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
>> 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
>>> 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
>> 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.
> Unsubscribe & other changes: http://lists.boost.org/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk