On Fri, Mar 1, 2024 at 5:04 AM Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hello,
>
> Il 01/03/24 06:45, Robert Sitton via Std-Proposals ha scritto:
> > Hello again! I am here to propose the addition of three new utility
> > functions to the C++ Standard Library: std::contains, std::contains_any,
> > and std::contains_all. These functions are intended to improve direct
> > and efficient queries on containers and ranges, filling a gap in the
> > current C++ standard that affects both the readability and
> > maintainability of code.
> >
> > Here's a quick outline of the proposed utilities:
> >
> > * std::contains: checking for a single value within a range or
> container.
> > * std::contains_any: Determines if any of a set of specified values
> > exist within a range or container.
> > * std::contains_all: ensures all specified values are present within a
> > range or container.
>
> I'm profoundly puzzled by this proposal.
>
>
> * Right now your std::contains specification *is* std::ranges::contains.
>
> https://eel.is/c++draft/alg.contains
>
> Why should we have duplicate functionality?
>
> * std::contains_any also already "almost" exists
> (std::ranges::find_first_of), so once more, what's the goal here?
>
> * Your functions are defined on ranges, and as such, should live in the
> std::ranges namespace. Why are they not there?
>
>
> > These utilities utilize concepts for compile-time type checks to ensure
> > compatibility and usability, and they are defined for all STL
> > containers, strings, and ranges. Their implementation guarantees
> > efficiency by using std::ranges::find, std::ranges::any_of, and
> > std::ranges::all_of.
>
> This sounds precisely what *not* to do, and how to guarantee terrible
> efficiency.
>
> If you want to check if a std::unordered_set contains a value, you call
> `set.contains(value)`. You certainly don't want to call
> `ranges::find(set.begin(), set.end(), value)`, turning a avg. O(1)
> operation into a O(N).
>
> `std::contains` as a generic operation only makes sense if it's a
> customization point, with `std::ranges::contains` (...why bother with
> find?) as a linear fallback in case the container doesn't know any better.
>

In order to have this, you'd have to figure out how to solve the problem
that ranges::contains(r, v) is equality-based on r.contains(v) might not be.

For instance:

struct Point {
    int x, y;
    friend auto operator==(Point, Point) -> bool = default;
};
struct JustXs {
    auto operator()(Point a, Point b) const -> bool {
        return a.x < b.x;
    }
};

int main() {
    std::set<Point, JustXs> points = {Point{1, 2}};
    bool a = points.contains(Point{1, 3}); // true
    bool b = std::ranges::contains(points, Point{1, 3}); // false
}


>
> And even then, I'd argue that I want first and foremost to have
> `std::vector<T>::contains` (ditto for all the other containers). I'm
> sick and tired of disrespecting C++ users by not offering them this sort
> of super-basic convenience, in the name of "purity" and "minimalistic"
> interfaces. It only took [checks notes] *25 years* to finally have
> std::string::contains; I hope the tide is turning.
>
> So, IMHO, the only possible rationale for something like
> `std::ranges::contains_any` should be "it's a shortcut for
> `find_first_of(b, e, v) != e`, just like `contains` is a shortcut for
> `find(b, e, v) != e`". I don't have any data on how much this is really
> needed (sounds like a niche use case), but I wouldn't necessarily oppose
> the idea.
>
>
>
> > The addition of std::contains and its related functions could be a major
> > advancement in the way containers are manipulated in C++. These tools
> > are highly beneficial for developers, providing them with the ability to
> > write clearer, more efficient, and robust code. They also improve the
> > readability of the code and reduce the amount of boilerplate required
> > while focusing on expressiveness and intent. Additionally, these
> > functions simplify common container operations, bringing C++ more in
> > line with functionality found in other major programming languages.
>
> These are extraordinary claims, unsupported by extraordinary evidence in
> the paper. And, I repeat, I say that as someone who would love to have
> vector::contains!
>
>
>
> > I have attached a detailed proposal document to this email. This
> > document includes a comprehensive rationale, technical specifications,
> > implementation examples, and anticipated impact. I believe that these
> > additions will be highly beneficial for the C++ community. I am eagerly
> > looking forward to receiving your feedback and suggestions for further
> > improvement.
>
> * The "comprehensive" rationale is 4 lines.
>
> * You say "Developers resort to verbose, error-prone patterns." and not
> show even one of them.
>
> * "offering concise, intuitive syntax that aligns with modern
> programming practices." What programming practices? Did you run a survey
> asking what developers would prefer between
>
> 1) if (std::ranges::contains(v, 42)) { ~~~ } // status quo
> 2) if (std::contains(v, 42)) { ~~~ } // proposal (?)
> 3) if (v.contains(42)) { ~~~ } // how it looks like in
> every other programming language and what I'd love to see
>
> ?
>
> * The technical specifications are highly imprecise/bugged, but that's
> something to nail down after the design.
>
>
>
>
> > This communication contains confidential information and may be
> > privileged. If you are not the intended recipient or believe that you
> > have received this communication in error, please reply to the sender
> > indicating that fact and delete the copy you received. You should also
> > not print, copy, re-transmit, disseminate, or otherwise use the
> > information unless expressly indicated in this communication.
>
> For the future: please get rid of this email suffix.
>
> --
> Giuseppe D'Angelo
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>