Talk:cpp/algorithm/ranges

[edit] Which navbar should [indirectcallable.indirectinvocable] and [alg.req] be under?

I've noticed neither of them are listed under cpp/iterator, nor are they under cpp/algorithm/ranges. I'd prefer for them to be under cpp/iterator, since that's where they're included from, but I can see the benefits to putting them in both. (I'd caution against exclusively keeping them in cpp/algorithm/ranges, as that's not intuitive for folks who also consult the IS.)

Cjdb (talk) 09:33, 29 June 2020 (PDT)

[edit] Niebloids rationale

The function-like entities described on this page are algorithm function objects (informally known as niebloids), that is:

• Explicit template argument lists cannot be specified when calling any of them.
• None of them are visible to argument-dependent lookup.
• When any of them are found by normal unqualified lookup as the name to the left of the function-call operator, argument-dependent lookup is inhibited.

This arbitrary seeming set of requirements had me scratching my head for a little while before finding this example in the standard:

void f() {
  using namespace std::ranges;
  std::vector<int> vec{1,2,3};
  find(begin(vec), end(vec), 2); // Calls std::ranges::find
}

std::find would normally be a better match due to the iterator arguments having the same type, but because a niebloid is found via unqualified lookup, ADL is not performed to find std::find. The other two points are presumably just consequences of implementing niebloids as function objects in order to achieve the prioritised lookup for the above use case.

If the above is indeed true, then I think it's worth having it noted somewhere, such as the top of this page? --Ybab321 (talk) 05:52, 28 July 2020 (PDT)

-- Hmm, interesting. I agree, this should be mentioned. --Space Mission (talk) 14:57, 28 July 2020 (PDT)

"Niebloids are not guaranteed to be objects. They are specified as magical function templates with enough weasel wording to allow them to be implemented as objects, but no more.", said by T.C.. It seems that decltype(std::ranges::find) is allowed to be ill-formed.
Perhaps we can say "During name lookup in function call expressions, they behave as if they are implemented as function objects."--Fruderica (talk) 23:14, 28 July 2020 (PDT)

I'm happy with how the current cpp/ranges/niebloid template describes niebloid implementation. I just think it's a non-straightforward set of properties to have in the first place; is the entire purpose of those properties really just to inhibit ADL? --Ybab321 (talk) 08:00, 30 July 2020 (PDT)

Plopping this article here for future reference https://brevzin.github.io/c++/2020/12/19/cpo-niebloid/ --Ybab321 (talk) 12:16, 23 December 2023 (PST)

[edit] Common structured return types (?)

The common structured return types of some rangified algorithms and uninitialized-memory functions should be described somewhere else in addition to the <algorithm>, since it is obviously inconvenient to seek them out in the synopsis itself.

namespace ranges {
  // algorithm result types (see definitions at the end)
  template<class I, class F> struct in_fun_result;
  template<class I1, class I2> struct in_in_result;
  template<class I, class O> struct in_out_result;
  template<class I1, class I2, class O> struct in_in_out_result;
  template<class I, class O1, class O2> struct in_out_out_result;
  template<class T> struct min_max_result;
  template<class I> struct in_found_result;
  ...
}

Should we create 7 separate pages for them? 🤔 --Space Mission (talk) 13:20, 25 December 2020 (PST)

I think we should. --D41D8CD98F (talk) 19:34, 25 December 2020 (PST)

Ok, I'll do it. --Space Mission (talk) 01:40, 26 December 2020 (PST)

[edit] predicats + projections

Isn't one predicate enough? Why do I need a projection of the elements? Dmi3 (talk) 11 Feb 2025

you don't; every algorithm that accepts both a projection and a predicate can be invoked without a projection, but with a more complex predicate. It's just convenience, especially when you can use a library predicate to avoid writing code; consider std::ranges::lower_bound(points, x, {}, &Point::x), std::ranges::sort(points, {}, &Point::x);, and std::ranges::upper_bound(points, x, {}, &Point::x) - without projectinos you will need to write three different predicates without mistakes here (can you tell without looking up which parameter goes first in upper and which in lower?). --Cubbi (talk) 07:37, 11 February 2025 (PST)

✔ Done Dmi3 (talk) 11 Feb 2025