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

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2024-12-18 09:29:20

> You may say that having member function 2 times is fine since it duplicated
> just 2 times, but we also have
>
> std::set<Key,Compare,Allocator>::contains
> std::map<Key,T,Compare,Allocator>::contains
> std::unordered_set<Key,Hash,KeyEqual,Allocator>::contains
> std::unordered_map<Key,T,Hash,KeyEqual,Allocator>::contains
> std::multiset<Key,Compare,Allocator>::contains
> std::multimap<Key,T,Compare,Allocator>::contains
> std::unordered_multiset<Key,Hash,KeyEqual,Allocator>::contains
> std::unordered_multimap<Key,T,Hash,KeyEqual,Allocator>::contains
>
> If you say this is just some modern C++ nonsense:
> Since C++98 containers had empty member function although it is trivially
> implementable with free function empty. Here not even talking about
> "complicated" C++17 std::empty that understands C arrays/std::array/...,
Actually this a good point why there is no clear superior approach:
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
C++20 introduced  a member function that could have been a free function 
-> Seems like the contrary
> And as Barry
> wrote 2 most common operations on map are insertion and lookup. So I
> believe lookup is definitely important enough to get
> nicer syntax.

I got to agree somewhat.

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