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

From: Ivan Matek (libbooze_at_[hidden])
Date: 2024-12-18 12:38:20

On Wed, Dec 18, 2024 at 10:29 AM Alexander Grund via Boost <
boost_at_[hidden]> wrote:

> C++98 used a member function that was generalized in C++17 to a free
> function -> Seems like time showed that free functions are better
>

That is not my reading of history. :)
I believe std::empty was added for use in generic functions as "poor man's
UFCS". Again this is *not* about UFCS, but please note this part of Herb
paper(underscore by me):

(new) It continues to lead to workarounds, including in the standard
> library, such as overloading operator| (e.g., ranges) or
> *providing nonmember versions of a limited set of common functions that
> cannot be made members on built-in types such as arrays (e.g., std::begin).*

I do not believe users writing non template functions are encouraged to
replace all their uses of .empty() with std::empty.
If you are aware of those suggestion in teaching materials or talks from
well known C++ experts please let me know.

>
>
> > few notes regarding suggested free function discussed:
> >
> >     1. Dispatching to member may be confusing. std::ranges::find /
> >     std::ranges::contains does not
> > <https://stackoverflow.com/a/75687947/>  dispatch
> >     to members if available
> Why does it matter to a user? The result is the same, although I'm not
> 100% sure for multi-map/set
>

Because it affects complexity of operation. And even if we agree this
design is better(I changed my mind on this during years and I no longer
consider it better) it is often better to have consistent inferior design
than inconsistent design where you have inferior and better design
"randomly" dispersed among functionality. This may sound trivial to you to
remember(e.g. boost::ofind dispatches to member, std::ranges::find does
not) , but you must remember that you are not even close to average
knowledge of C++.

> >     2. try_find seems like a wrong name. try_at makes sense since at has
> >     precondition(unless you use exceptions for control flow :) ), while
> > find does
> >     not, i.e. it can fail. So it is kind of weird to have a prefix that
> says
> >     try in algorithm that has same "success rate" as find.
> I'd definitely want to have "find" or "lookup" in the name.
> `map.try_at(key)` makes we wonder what is tried at the key.
> Maybe `map.get(key)` as it always "gets something" if you want. But that
> is bike-shedding for after a decision.
>

I agree it is premature, but I still believe it is important to be
consistent, again not for experts, but for average user. try_at already
exists in Boost.Json, and it is name suggested by Barry in his blog, for
find version afaik Barry did not provide suggestion, and there is no that
functionality in Boost at the moment afaik.