On Wed, Jul 28, 2021 at 3:20 PM Edward Catmur via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Wed, 28 Jul 2021 at 20:16, Kyle Knoepfel via Std-Proposals <
> std-proposals_at_[hidden]> 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
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*