# 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::optionalstd::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.