Re: [boost] Boost.Outcome review - First questions

Subject: Re: [boost] Boost.Outcome review - First questions
From: d25fe0be_at_[hidden]
Date: 2017-05-22 16:08:54

>> # Our |value_or()| member functions pass through the reference rather than
>> returning by value (we don't understand why the LEWG proposal does
>> except that |std::optional<T>| does, which itself is a bad design choice
>> and it should be changed).
>> 
>> Well, what is the advantage to returning by reference?
> 
> You don't cause .value_or() to surprisingly fail to compile when T lacks
> a move or copy constructor. The reference returning edition does not
> impose the requirement for T to have a move or copy constructor. This
> choice for .value_or() interferes less on end users.
> 
> The fact optional implemented .value_or() with a return by value is a
> mistake. Expected need not repeat that mistake.

I might have missed something, but if .value_or() returns a reference, won't:

auto &&s = std::optional<std::string>{}.value_or("temporary"s);
std::cout << s << std::endl;

triggers undefined behavior? 

'"temporary"s' is destroyed right after the declaration of 's', hence 's' is
a dangling reference.

By requiring .value_or() to return by value, this should just work.