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

From: Neil Groves (neilgroves_at_[hidden])
Date: 2024-12-19 17:42:55

>
> Sure, that's just another opinion.
>
> I'm just relaying my experiences having talked with other developers across
> multiple languages and programming chats.
>

Many of the developers on this list have also spoken to other developers
and have equally valid experiences to draw from.

>
> In reality, I don't think anyone wants `try_find(my_vector)` because you
> don't normally do try_find on a container like vector.
>
> It's important to follow the principle of avoiding over-engineering and
> under-delivering.
>

Many developers on this list have designed one or two software projects.
The experienced developers are not learning from the memes that you are
repeating.

It isn't over-engineering to try and design the solution to avoid
unnecessarily requiring the modification of every associative container. If
the solution genuinely required it, then fine, but so far this does not
appear to be necessary. Thought, rational debate, and consideration of
alternatives early in a project are not symptoms of over-engineering. They
are a signal of experienced developers that are trying to ensure that the
subsequent time invested in the SDLC for the feature has a good return on
investment.

Since I maintain Boost.Range by exploring the possibilities for
non-intrusively adding the feature-set it would make it possible for me to
provide the entire solution. If we require intrusive modification we have
our own associative containers to change, the std ones would need to
change, and then user-supplied ones would also need to be modified. We
would need a very considerable advantage to go this route since it
inevitably would mean divergence while libraries adopted the new approach
at different speeds even if we guaranteed eventual convergence.

A non-intrusive solution, if it indeed works as hoped, allows me to provide
and ship something that works for existing associative containers, the new
ones in C++26, and conforming containers obtained from elsewhere. This is a
huge, objective, design advantage. If the non-intrusive approach is limited
to containers then I would make a pull request for Boost.Container but the
same broad advantage would remain.

>
> The value proposition here is dubious in the first place because it relies
> on using Boost.Optional in an API and most people aren't huge on using
> Boost versions of STL components anymore in 2024.
>

I find at places of work that like money the decision about what to use is
based upon what works and provides a good return on investment. The
original idea, you posted, can be made immune to being tied to
Boost.Optional easily. Each and every premature / unnecessary coupling /
intrusive decision brings with it the chance to have a show stopping
objection for a user. It's one of the reasons we are trying to keep the
essence of the original request / proposal while trying to help shape it in
a way that: 1. can be implemented without requiring changes to an
unnecessarily large number of libraries, and 2. explore the other similar
cases where the current interface is deficient to see if this can stimulate
even more improvement.

>
> - Christian
>
>
Neil