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

From: Christian Mazakas (christian.mazakas_at_[hidden])
Date: 2024-12-20 22:58:19

On Fri, Dec 20, 2024 at 11:37 AM Neil Groves <neilgroves_at_[hidden]> 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<T&>`, 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
`<boost/unordered/unordered_flat_map.hpp>`, 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