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

From: Neil Groves (neilgroves_at_[hidden])
Date: 2024-12-17 17:16:02

On Tue, 17 Dec 2024 at 16:50, Janko Dedic <jankodedic2_at_[hidden]> wrote:

> 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.
>

My language was too strong. There are objective quality factors that are
better with the non-member function approach, as per Item 23, which I
assume is uncontroversial. I have miscommunicated to the point of
expressing something I don't believe! There are compensatory advantages to
the familiar member function syntax. Of course, the syntax is often less
jarring to use member functions, and the usual IDE point is valid. I
overstated, what I considered to be the accepted position, that despite
those benefits, the intrusive, non-extensible and encapsulation drawbacks
had settled the debate, generally. It's always good to reconsider with the
full available context.

>
> 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.
>

Uniform syntax would indeed be wonderful.

> 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.
>

At least two options. I can think of at least 4, and with all the wisdom on
the list I'm hoping someone will come forward with a better one that I've
failed to consider.

Apologies for my communication mistake with respect to the member vs
non-member approaches. Of course, I have no authority to demand a
particular approach be taken. My hope remains that by putting some code
together it will help further the discussion. Nothing I do or say should be
taken as closing down the willingness to consider and debate alternatives,
that is exactly opposite to my aims.

Neil Groves