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

On Thu, Dec 19, 2024 at 7:52 AM Vinnie Falco 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

On Thu, 19 Dec 2024 at 16:19, Christian Mazakas via Boost < boost@lists.boost.org> wrote: 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