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

On Tue, 17 Dec 2024 at 16:46, Christian Mazakas via Boost < boost@lists.boost.org> wrote:

On Tue, Dec 17, 2024 at 8:00 AM Neil Groves via Boost < boost@lists.boost.org> 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.

I really don't think this is true at all.

For one, unordered containers have transparent lookup which I'd imagine might actually complicate things.

My opinion on it is that people really only want optional interfaces in the associative containers and nothing else.

While this is probably true for your specific use-cases, this is false for "people" assuming I count as a person! I have frequently come across production code that benefits from looking up configuration in a map and using a default value if the key is not present. I've needed to do this frequently and I see this implemented in code frequently.

You can feel free to objectively totally prove me wrong here but I think if we just updated the base set of containers, that'd make all of our users happy. Especially because member functions work better with code completion and Intellisense.

When I referred to objectively being superior earlier this was not aimed at making a person right or wrong. I was referring to the objectively superior re-usability, the objectively looser coupling, and the broader applicability. These are objective quality factor advantages. I was implicitly inviting contrary opinions and ideas that would open my mind to the merits of the alternatives. The non-member solution is open and would work non-intrusively with other containers that users may have implemented.

A good rule of thumb in software engineering is to start with the concrete and abstract later.

I have many years of experience where the default value non-member version adds benefits. I've implemented the non-member function and found it useful in large scale production code. It happens to generalize to supporting optional too. While it is wise to avoid excessive abstraction. Sometimes we have prior knowledge about the pattern of problem and established criteria from which to make an informed decision. This is the case with member vs non-member functions, as discussed in Effective C++ Item 23 and elsewhere. The non-member function is looser coupled, and has the well-known, published advantages. We famously prefer non-member functions for well substantiated reasons. Therefore if we have the choice and there isn't a compelling advantage, we would run with the established superior default choice. The burden of proof is on the argument for preferring a member function.

- Christian

I shall complete my prototype, but obviously do not demand that this is the approach that is taken. I simply thought it may help make the one approach I am proposing more concrete and easier to modify and we consider the design alternatives. If the member-function is the better solution it should make this clearer by allowing easy demonstration of the disadvantages. Neil Groves