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

You may say that having member function 2 times is fine since it duplicated just 2 times, but we also have

std::set::contains std::map::contains std::unordered_set::contains std::unordered_map::contains std::multiset::contains std::multimap::contains std::unordered_multiset::contains std::unordered_multimap::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.