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

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

On Thu, 19 Dec 2024 at 16:19, Christian Mazakas via Boost <
boost_at_[hidden]> wrote:

> On Thu, Dec 19, 2024 at 7:52 AM Vinnie Falco <vinnie.falco_at_[hidden]>
> wrote:
>
> >     try_find( users, user_id ).map(
> >         [](auto& user)
> >         {
> >             user.status = deactivated;
> >             return user;
> >         });
> >
>
>  Yup, exactly.
>
> My point was that users don't want this compared to the method chaining
> version and
> I think the code here kind of speaks for itself.
>
> users.try_find().map() is the preferred API over try_find(user).map().
>
> It seems to me this is just a repeated assertion that you prefer the
syntax. Do you have sources to substantiate your view of the Boost users? I
don't feel that I know with any certainty which syntax the users would
prefer. What evidence do you have to support this assertion?

I am not arguing that your view is incorrect. Some very valid points have
been made and I have accepted that the member function approach genuinely
has more appeal than I initially thought. I was influenced more by the
fact-based reasons and references. I think that many of us fall foul of
https://en.wikipedia.org/wiki/Argumentum_ad_populum . When many smart
people do or believe something there is often merit of course, but we
should look for the decisions and the outcomes from those decisions.

Of course, my failure to provide code on time has hindered the ability to
point at my approach and find fault with it. The chance to mock my
inevitably faulty thinking will be provided later!

> - Christian
>
>
I have spent considerable time working on this problem and think that this
is a very interesting problem indeed. The member / non-member syntax is a
trivial distraction in terms of the substantive design decisions.

One aspect that strikes me about all of our alternatives is that none of
them work particularly well when we are using multi_ associative
containers. a map algorithm (in the sense of boost::optional::map) on the
equal_range mapped values would work for both cases, but definitely needs
some thought. I agree with you that the optional map member function adds
value by eliminating some of the error cases. I'm trying to keep everything
from this approach, generalizing it for multi- associative containers while
not losing anything for single-value associative containers that optional
provides.

If we have a mechanism to replace an empty range with a single element
range, we can implement your user map example in a way that works for
single and multi containers. I need a little more time to be able to
evaluate how general I can go without compromising ease of use, or
performance. It is a rather interesting problem space. I appreciate the
discussion. It seems likely that we can make a considerable improvement.

I had hoped to have some code to post already, but I've been finding more
design alternatives to evaluate.

Regards,
Neil