Re: [boost] [optional] Safe optional

Subject: Re: [boost] [optional] Safe optional
From: Olaf van der Spek (ml_at_[hidden])
Date: 2014-11-20 05:20:35

On Thu, Nov 20, 2014 at 11:00 AM, Andrzej Krzemienski
<akrzemi1_at_[hidden]> wrote:
>> > Note that the proposed expected<T, E> has the same "identity crisis":
>>
>> It'll probably face the same resistance.
>> Comparing no value and a value simply doesn't make sense and code like
>> shown is a real bug.
>>
>
> I disagree with this statement. In case of optional<T> having no value of T
> is deliberately treated as a yet another value. This has a well defined
> purpose. It is covered in the documentation here:
> http://www.boost.org/doc/libs/1_57_0/libs/optional/doc/html/boost_optional/quick_start/storage_in_containers.html

By containers you specifically mean map, right?
Unordered map for example would not require operator<

Containers (maps) always come up as the primary rationale for operator<
However, the user could also define his own comparison function for
this purpose.

Perhaps other use cases of operator< could be presented.

> the docs also recommends NOT to use optional<T> to signal a potential
> error/difficulty in computing T:
> http://www.boost.org/doc/libs/1_57_0/libs/optional/doc/html/boost_optional/tutorial/when_to_use_optional.html
> .
>
> This is the choice made for optional<T>. The authors of expected<T, E> may
> want to choose a different model.
>
>
>> What's wrong with being explicit with what you want, especially in
>> ambiguous situations like those mixed comparisons?
>>
>
> Nothing wrong with that. It is just not the job for optional. Perhaps a job
> for expected<T, E>.

But is it what people have problems with isn't it?

-- 
Olaf