C++ Logo

std-proposals

Advanced search

Re: Yet another member function for std::map

From: Andrey Semashev <andrey.semashev_at_[hidden]>
Date: Wed, 28 Jul 2021 22:44:39 +0300
On 7/28/21 10:19 PM, Edward Catmur via Std-Proposals wrote:
> On Wed, 28 Jul 2021 at 20:16, Kyle Knoepfel via Std-Proposals
> <std-proposals_at_[hidden] <mailto: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>>?

Why does it have to be so complicated? If we really want an optional
then just make optional<V&> work.

Though in this case I would prefer V*.

Received on 2021-07-28 14:44:45