On Thu, Dec 19, 2024 at 9:43 AM Neil Groves <neilgroves@gmail.com> wrote:
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.
I wouldn't really say it's a "meme" in the modern 2024 sense. It's just a saying I heard and it stuck with me. I'd like to say that I'm sorry because I didn't mean to imply any of that, either. I never said your experiences were invalid. I also never said you don't have experience. If you got that impression, that certainly wasn't my intent. The thing is, a free function vs a member function and all this stuff doesn't genuinely have an "objectively correct" approach. You can decide on the trade-offs and have a set of favorites but it's not like this is literally objectively correct or incorrect in an empirical sense. The only requirements are that there exists some mechanism to go from `container&` to `optional<T&>`. Now _that_ is something that can be objectively correct or incorrect. Being completely honest, I don't really have a strong opinion here either way. The thing is, we don't actually know if people are even going to use this kind of construct in the first place and it's just way easier to add try_find to e.g. `boost::unordered_flat_map` and call it a day. If users buy into the construct and they want the free function version, they'll let us know. - Christian