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

From: Neil Groves (neilgroves_at_[hidden])
Date: 2024-12-17 17:01:23

On Tue, 17 Dec 2024 at 16:46, Christian Mazakas via Boost <
boost_at_[hidden]> wrote:

> On Tue, Dec 17, 2024 at 8:00 AM Neil Groves via Boost <
> boost_at_[hidden]>
> 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<T&> 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