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

From: Ivan Matek (libbooze_at_[hidden])
Date: 2024-12-21 11:48:31

On Fri, Dec 20, 2024 at 11:58 PM Christian Mazakas via Boost <
boost_at_[hidden]> wrote:

>
> 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.
>
> 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 fully agree with everything here(except std:: vs boost optional is a bit
more complex, see bellow), I am fully aware of costs to enable nice syntax
for users.
I do not think they are negligible, but I think they are worth it.

My experience is also that users prefer std:: alternative if it is in C++.
Issue here is more complicated since
it is still unclear if optional<T&> will be in C++26, and because monadic
operations have different member function names.

Regarding boost::optional overhead: as mentioned before on my machine
adding optional increased preprocessed line count by around 3%(compared to
same map header without #include <boost/optional.hpp> )
Also not sure if ranges code compiles faster than optional without making
some realistic compile test cases since I presume optional uses are easier
to compile than ranges version.

On Sat, Dec 21, 2024 at 11:02 AM Neil Groves via Boost <
boost_at_[hidden]> wrote:

>
> So in addition to solving the original problem it reduced the need to teach
> all the special divergent ways of performing find. That IME is a problem to
> teach and remember and having no unified optimal syntax for lookup is a
> pain sometimes in generic code. We have to know it is a map, alter the code
> to optimize the lookup.
>

As mentioned before std::find/std::contains do not do dispatch to members
so it is unclear if this is easier to teach to people when existing
algorithms do not do dispatch. And if we provide find
it makes sense to provide all other algorithms with faster member
implementations like contains and count.

>
> Ultimately though, we all ended up going in different directions and going
> nowhere!
>
> Even if we do not agree in this particular use case I can understand that
some users might find :) use for dispatching free function in generic code,
although it scares me we are encapsulating complexity.

> Thus my syntax examples were to address the OPs proposition and attempt to
> hit a defined optimal syntax in the problen statement.
>
> You are spot on though. This is all totally pointless.
>
> Not sure why you feel this way, we can disagree, but does that mean we can
not learn anything from discussion?
I still prefer member function, I will not lie about that, but people here
referenced P2011 that was super interesting(although I knew of pizza
operator before I never studied it in detail), I have googled up P3021, and
many comments here were interesting.