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

sob., 21 gru 2024 o 12:49 Ivan Matek via Boost napisał(a):

On Fri, Dec 20, 2024 at 11:58 PM Christian Mazakas via Boost < boost@lists.boost.org> 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`, 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 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 ) 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@lists.boost.org> 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