Talk:cpp/algorithm/ranges

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)

Niebloids rationale

---

The function-like entities described on this page are 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.

In practice, they may be implemented as function objects, or with special compiler extensions.

---

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)

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)