Talk:cpp/experimental/ranges

I haven't even added Clause 7 yet and this already feels too long. Separate pages for clauses 4-7, maybe? But then it might feel too short. T. Canens (talk) 15:02, 2 December 2016 (PST)

[edit] Qualified names in signatures?

Our usual style is to use fully qualified names in signatures (it allows automatic links and all that), but this seems...a little too much:

Even this seems a bit excessive:

And binary_search isn't even close to the worst. Any ideas? T. Canens (talk) 20:54, 5 January 2017 (PST)

I think it would work if autolinker could pick up from just the most-nested namespace. filesystem::path, ranges::less, etc. I am looking at Networking TS right now (NB comments round) and that is going to be another handful of std::experimental::net::whatevers. To drop full qualifications completely, autolinker would have to be come really smart.. or the dcl templates would have to allow manual linking and lots of tedious editing. We'll need User:P12 to weigh in on that. --Cubbi (talk) 06:11, 6 January 2017 (PST)

Another option could be to start wrapping dcls in namespaces, as in

namespace std::experimental::ranges {
  template <ForwardIterator I, Sentinel<I> S...
}

but again not clear if autolinker can be smart enough to link ForwardIterator here. --Cubbi (talk) 11:39, 6 January 2017 (PST)

If I understand correctly, linking in {{dcl}} (via {{c/core}}) is powered by GeSHi's keyword links feature and controlled by MediaWiki:Geshi-keyword-list-cpp rather than by MediaWiki:Autolinker-definition-cpp (which powers {{lc}}). So unless we want to hack GeSHi, we can try altering the list to make it treat, e.g., filesystem::path as the keyword rather than std::experimental::filesystem::path. The drawbacks are 1) the std::experimental:: part presumably won't be linkified, and 2) potential conflicts when something gets merged into the standard (e.g., if this had been done for the filesystem TS, filesystem::path would have been pointing to the TS version, and then we can't make it point to the IS version). One way to solve it might be to invent a "new language" for subpages of cpp/experimental so that they get a different keyword list, and then we can make filesystem::path go to std::experimental::filesystem::path on cpp/experimental/foo but std::filesystem::path on cpp/foo, but that 1) requires server-side changes and 2) could be hard to maintain since we would be duplicating a lot of stuff. T. Canens (talk) 19:50, 10 January 2017 (PST)

Revisiting this again, I've been using the ranges::foo form since it's about as short as possible, while still permitting automatic linking without server-side changes. The "conflict" part isn't a significant issue for the Ranges TS at least, since the intent is for it to eventually become std\d+::meow rather than std::ranges::meow. So we just have to tell GeSHi that the "keyword" is ranges::foo rather than std::experimental::ranges::foo. (Autolinker is trickier, but it's also used in much fewer places. Worst case scenario, we can easily create a wrapper template so that {{lc-rng|foo}} does the equivalent of {{lc|std::experimental::ranges::foo|ranges::foo}}.) T. Canens (talk) 12:26, 23 January 2017 (PST)

I have some plans and even some prototyped code for a new autolinker that would be namespace-aware. That would solve the verbosity issues in the long-term. We could even drop std:: and add something like on-hover tooltips that would show fully-qualified names. I think that hacking the keyword definitions is a good solution short-term. --P12 01:58, 1 February 2017 (PST)

[edit] Should we keep concept rows in the parameters table?

Take cpp/experimental/ranges/algorithm/sort for an example, to what extent should we bother documenting the requirements in the table (with {{par req named}} etc.)? Note that Sortable<I, Comp, Proj>() eventually decomposes into a large number of requirements, not all obvious. (Let's assume that we have all the links and pages in place so with enough clicking and note-taking one can figure it out from the signature and the definition of the various concepts.) T. Canens (talk) 15:17, 20 January 2017 (PST)

I would think the point of named concepts (as opposed to individual constraints) is that the user doesn't need to decompose them, so Sortable is the only requirement that should be listed. Even in today's library, if something requires LegacyRandomAccessIterator, we don't also say it is required to be LegacyBidirectionalIterator and everything else down to DefaultConstructible --Cubbi (talk) 18:38, 20 January 2017 (PST)

If that's the case, then we wouldn't need to bother since it's implied in the signature. The problem is that some of the constraints are not obvious (projected being the worst offender, because it is used all over the place and adds a IndirectRegularInvocable<P, I> constraint via its template-parameter-list), and it's really hard now to answer a question like "I have a vector of Ts, what must T satisfy in order for sort to work?" Previously, the answer is fairly straightforward. Now we have to wade through a large tree of concepts and multiple customization point objects with complex definitions before we can figure out the answer and be certain that we didn't miss anything. T. Canens (talk) 19:16, 20 January 2017 (PST)

After thinking about this some more, perhaps it's better to just use Sortable on the ranges::sort page, and then decompose as needed on the concept page as part of the notes. I still think we need to decompose sprawling concepts like Sortable somewhere, since they represent a pretty big tree of requirements, and I think we should at least break it down into easier to digest pieces.

The iterator concepts are rather different: they have a ~linear hierarchy, so the requirements are easier to pin down, and in any event, those requirements are most interesting to people who write iterators, not people who use them (who can just check the iterator category in the documentation etc. and match it against the algorithm's requirement), whereas here the requirements are of great interest to people who use sort. T. Canens (talk) 01:33, 23 January 2017 (PST)

I'm currently inclined to think that we should partially decompose:

• "sort requires Sortable" or "merge requires Mergeable" is basically circular and isn't informative;
• Sortable<I, R, P> and especially Mergeable<I1, I2, Out, R, P1, P2> have way too many parameters, making them tricky to follow and also hard to define;
• In general, I think we don't need to decompose a concept if its requirements can be generally described in a sentence of reasonable length, possibly with the aid of well-established terms of art (like "random access iterator").

So, for sort, I would decompose it down to

• ranges::RandomAccessIterator<I>
• ranges::Sentinel<S, I>
• ranges::Sortable<I, Comp, Proj>, decomposed into

• ranges::Permutable<I>, decomposed into

• ranges::ForwardIterator<I> (subsumed by RAI on the algorithm)
• ranges::IndirectlyMovableStorable<I, I>
• ranges::IndirectlySwappable<I, I>

• ranges::IndirectRegularUnaryInvocable<Proj, I> (required by projected), partially decomposed into

• ranges::CopyConstructible<Proj>
• A pile of RegularInvocables that can be described in a sentence.

• ranges::IndirectStrictWeakOrder<Comp, ranges::projected<I, Proj>>, partially decomposed into

• ranges::CopyConstructible<Comp>
• A pile of StrictWeakOrder requirements, again described with words.