Re: [boost] On free functions versus member functions

pt., 20 gru 2024 o 08:46 Ivan Matek napisał(a):

On Thu, Dec 19, 2024 at 11:20 PM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:

...

czw., 19 gru 2024 o 18:04 Vinnie Falco via Boost napisał(a):

In C++ we have what we have, but technically we could think about "encapsulation" and "member function notation" as two orthogonal things.

Can you elaborate? For me without UFCS this is *not* orthogonal. For example my reading of P3021R0 https://open-std.org/JTC1/SC22/WG21/docs/papers/2023/p3021r0.pdf is that std::begin is poor man's UFCS. Maybe I misunderstood you.

...

I am personally not sold by the "discoverability" argument, because I mostly code in vim where I do not get any hints from the IDE anyway.

I personally do not use exceptions(except one I got from std::/libraries), that does not mean I would oppose improvements for people who use exceptions. Not every improvement needs to benefit 70+% of users.

On Fri, Dec 20, 2024 at 12:57 AM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

std::unordered_map< int, char > m;

upgrade(m).try_find( 1 ).map( []( auto&& v ) { std::cout << "not empty"; return v; } );

I do not think people will be happy to use this pattern because it beside it being verbose it requires wrap on every use, would be better if it was a type wrapper that inherits public interface of container e.g. in class you have member boost::fancy> user_id_to_user_; // has find, size, ... + try_at

so every use of user_id_to_user_ does not need upgrade wrap call.

Issue here is that you can not inherit from containers(or you can, but you shouldn't). This is a well known issue in C++.

Could you explain what the issue is? I do not believe I have ever heard of it. Regards, &rzej;