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)

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 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., , etc. I am looking at Networking TS right now (NB comments round) and that is going to be another handful of s. 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


 * 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., as the keyword rather than . The drawbacks are 1) the  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,   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  go to std on cpp/experimental/foo but std 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 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  rather than . So we just have to tell GeSHi that the "keyword" is  rather than . (Autolinker is trickier, but it's also used in much fewer places. Worst case scenario, we can easily create a wrapper template so that foo does the equivalent of std::experimental::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)

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 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 is the only requirement that should be listed. Even in today's library, if something requires, we don't also say it is required to be  and everything else down to  --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 ( being the worst offender, because it is used all over the place and adds a constraint via its template-parameter-list), and it's really hard now to answer a question like "I have a vector of s, what must  satisfy in order for  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 on the  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  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 . T. Canens (talk) 01:33, 23 January 2017 (PST)

I'm currently inclined to think that we should partially decompose: So, for, I would decompose it down to
 * "sort requires " or "merge requires " is basically circular and isn't informative;
 * and especially 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").
 * , decomposed into
 * , decomposed into
 * (subsumed by RAI on the algorithm)
 * (required by ), partially decomposed into
 * A pile of s that can be described in a sentence.
 * , partially decomposed into
 * A pile of requirements, again described with words.
 * (required by ), partially decomposed into
 * A pile of s that can be described in a sentence.
 * , partially decomposed into
 * A pile of requirements, again described with words.
 * A pile of requirements, again described with words.
 * A pile of requirements, again described with words.

The indirect callable traits are odd because they bundle in a requirement that doesn't really belong. It may be possible to just call out the concept in the text description and not actually decompose it. T. Canens (talk) 14:42, 18 May 2018 (PDT)