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

On Fri, Dec 20, 2024 at 11:37 AM Neil Groves wrote:

As you know I've tried seeing how far I could get with some work in Boost.Range. I appreciate this isn't the solution you are dreaming of.

...

I wondered if reading this example line above if it didn't look quite as

horrific as perhaps you were imagining?

One unfortunate aspect of the original snippet is the boost::optional choice of the word "map" where we are also working with a concrete "map" container.

There is plenty of work to do if this is of interest to anyone. I would want to ensure there was no performance overhead, and currently I'm not entirely convinced that my initial implementation that uses the member equal_range is optimal. This is an implementation detail, which I would work through.

The value_or ( or front_or ) functionality for non-multi containers can be added in a similar manner, and be broadly usable for range algorithms. ... If this is of any interest to you I'll look at putting some of this into the develop branch of Boost.Range. If it is not interesting I shall continue on my branch and build a more compelling iteration that I shall land later.

I hope this helps

Fwiw, I don't mean to be a hater and I'm happy you're not discouraged. It's like I said, I don't actually have a strong opinion here either way. I'm with Andrey, I think the iterator API *is* the useful API. Typically, when I find something in a map, I'll either erase or do something else where reusing the iterator is a key part of everything. My whole thing was about what users actually wanted vs all the costs of everything else. In C++, we have basically unlimited power so we can honestly do basically whatever we want. I think most users just want `try_find() -> optional`, with `std::optional` and not Boost. Boost is okay as a polyfill, but users have told us ad nauseum that in 2024, they prefer STL versions. Second, I think the burden on users to opt into the perfectly generic version is too much for the little we're actually doing. For a user to now get the behavior they want, they'll have to depend on Boost.Range, include the Range headers and then setup their functional pipeline just to do something that could've been this: for (auto& user : users_map.try_find(user_id)) { user.status = deactivated; } To this end, the user doesn't have to include anything more than ``, which they would already have. The cool thing about Boost is that we're supposed to innovate and that means trying new things. I'm not saying Range-ifying everything is bad and I'm happy you're giving serious efforts into making it happen. I'm just trying to give my opinion about the potential reception of such efforts. It's fine on paper but I'm not sure we have users clamoring for the feature to manifest in this way. I'd be happy to be proven wrong. - Christian