On Wed, Dec 18, 2024 at 10:29 AM Alexander Grund via Boost < boost@lists.boost.org> 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.