Re: Adding optional<T&> find like method to associative containers in boost.

From: Janko Dedic (jankodedic2_at_[hidden])
Date: 2024-12-17 16:50:15

On Tue, Dec 17, 2024 at 5:00 PM Neil Groves via Boost <boost_at_[hidden]>
wrote:

> The free function is clearly the objectively superior solution. This is
> fact and is preferred over opinions no matter the authority.
>
> The member function approach is objectively inferior, and has no
> compensatory advantage.
>

There is no "objectively superior" solution here. The "compensatory
advantage" of a member function is the caller syntax. Something like
`map.get(key)` is easier to write and read, especially in more complex
expressions. Compare `map.get(key).value_or(other)` to `value_or(get(map,
key), other)`. For some libraries (like Ranges), the free function syntax
went from a minor nuisance to a deal breaker, so Ranges overload operator|
to compensate.

The only "objectively superior" solution here is a language feature (akin
to extension functions in C#, Swift, Kotlin etc.), which allows defining
non-member functions that are callable with member-like syntax.

Since we don't have that ideal solution right now, we have to recognize
that there are two options here, both with their pros and cons, and we have
to weigh them to make a decision.