On Wed, Jul 28, 2021 at 3:20 PM Edward Catmur via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Wed, 28 Jul 2021 at 20:16, Kyle Knoepfel via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Hi Barry,

Right...which is why I said the return type of value_for(...) would not be quite like std::optional.  So there seem to be four or five options to me:

1. std::map<K, V>::value_for(K const&) -> typename std::map<K, V>::value_handle, where map gains a nested type that behaves like std::optional<V&> would behave.  Yuck.
2. std::map<K, V>::value_for(K const&) -> V*, where a bare pointer, or some equivalent, is returned.  Also yuck.
3. std::map<K, V>::value_for(K const&) -> std::optional<V&>.  Requires convincing the standards committee to support reference-type template arguments for std::optional.
4. Something else I haven't thought of
5. Stop wanting this feature

I think 3 is the ideal solution, but the most unlikely to occur.  Option 1 is doable but I assume no one wants to add an additional type to std::map.  I fear 5 is the most likely solution, although it would sadden me.

4. optional<reference_wrapper<V>>? 

My understanding is that reference_wrapper was designed for only one use case: to survive decay-copy scenarios where using a normal reference would result in the referenced object being copied. And I don't think its use should be expanded beyond that. It is already starting to confuse beginners, who often think reference_wrapper is supposed to be a safer replacement for pointers or something like that.
Std-Proposals mailing list

Brian Bi