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

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2024-12-28 11:08:16

sob., 21 gru 2024 o 12:49 Ivan Matek via Boost <boost_at_[hidden]>
napisał(a):

> 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.
>

About these compile times with boost::optional, in Boost 1.87
Boost.Optional dropped a number of dependencies on other Boost libraries,
so I would expect the compile times to improve.

Regards,
&rzej;

>
>
>
> 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.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>