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

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2024-12-19 17:04:00

On Thu, Dec 19, 2024 at 8:19 AM Christian Mazakas via Boost <
boost_at_[hidden]> wrote:

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

In C++, free functions which operate on a concrete type or a type which
matches named requirements are considered to be part of the public API for
that type. std::swap is a good example, this is why cppreference.com lists
associated free functions under a section titled "Non-member functions:"

    https://en.cppreference.com/w/cpp/container/vector

Good library design means designing for C++. Therefore:

    Free functions should be considered equally ergonomic to member
functions.

Good encapsulation means giving an algorithm access to as few
implementation details as possible. Therefore:

    Prefer free functions when an implementation can use only the publicly
visible members of a type.

Scott Meyers elaborates on this:
https://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197

When designing a library you have to assume that the user knows C++. If
they don't understand the use of free functions, the solution is that they
should educate themselves, not to always use member functions. The free
function is better than the member function for several reasons:

    1. The implementation only needs to be written once
    2. Authors of new containers have less to implement
    3. The header file for the containers does not change; no need to
include <optional>
    4. Multiple free functions can exist, each returning their own optional
type, permitting std::optional and boost::optional to co-exist harmoniously.
    5. Better encapsulation: the free function does not have access to
private members
    6.

A common objection to the use of free functions is that the member function
is more discoverable, such as in an IDE. This problem is better solved in
the IDE, of which there are few, rather than solving it in the container of
which there are uncountably many. That is, if someone was to type "u." in
the IDE, then the autocomplete feature could show associated free functions
in addition to member functions. And when an associated free function is
selected, the IDE will change the member function call to become the free
function call syntax.

For all the reasons listed above, the free function is preferable to the
member function. As this allows the functionality of containers to be
extended without imposing additional work on all existing and future
container authors. And I do believe that we need better educational
resources, so the myth that member functions are somehow more ergonomic can
be decisively dismissed.

Thanks