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