Re: [boost] [optional] Safe optional

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]>
>> 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
>