This added comma (and the one above) go against the convention.

I added these for consistency with the constructor further above. I have no particular preference here other than consistency; please feel free to provide a PR to remove them.

Does R1 have some indirectly_-prefixed concepts? For R0, all are indirect_-prefixed.

Yes. In R1, only indirect_unary_predicate, indirect_relation, and indirect_strict_weak_order are indirect_; the rest are indirectly_ (including two that were previously Indirect not Indirectly).

Should view and range use \libconcept here?

Yes.

Library folk have a longstanding tradition of colloquially referring to:

• models of concept foo,
• instances of types that model concept foo,
• specializations of class template foo, and
• instances of specializations of class template foo

as "foos". (Aside: one of the best days of working on Ranges was when we finally created Iterator as a distinct concept so we could finally say what the Standard means everywhere when it talks about "iterators". One of the worst was when LEWG renamed that concept to input_or_output_iterator, once again breaking that connection.)

The introductions for the XX_view types take this colloquialism to the extreme: "ref_view is a view of the elements of some other range" very concisely states that specializations of ref_view model the view concept, and that the elements denoted by an instance of a specialization of ref_view are shared with some other instance of an object type that also models the range concept. The only real novelty I introduced in these bits of wording was to use code font to visually link the colloquial uses more strongly to the concepts to indicate that yes: when we say "view" here we actually mean the view concept.

So yes, I think all of these should be \libconcepted.

Should this be "in the \libconcept{view} concept"? If not, what view are we talking about?

IMO this should be the number of elements in the \libconcept{view}. A concept doesn't have elements, but an instance of some object type that models range (or a refinement thereof like view) does. Adding the word "concept" here wouldn't be consistent with the usage of the colloquialism and would cause confusion.

Should this be \libconcept{view}?

Ick, I hate this wording. What do "view-like" and "container-like" mean?

IMO this sentence should be The class template \tcode{view_interface} is a helper for defining \libconcept{view}s. or more formally ... defining class templates whose specializations model \libconcept{view}.

Should this be \libconcept{view} and \libconcept{range}?

Should this be "\libconcept{view}s"? And should it be "\libconcept{view} types"?

See also the use of "views", not \tcoded, a few lines down from here in the file. The terms "view" and "views" are used like this throughout the library. Are they referring to the "\tcode{view}s / \libconcept{view}s" above? If so, they should be fixed to use the same formatting, and if not, a definition of a "view" should be supplied. This is a common problem throughout the library for "predicate"s, "sentinel"s, etc.

This is a common problem throughout the library for "predicate"s, "sentinel"s, etc.

Yes, it is. And I failed to achieve consistency in [ranges], let alone the rest of the library. Maybe we should copy my comment above into an editorial issue and make a determination about whether or not it should be policy so we can enforce it library-wide rather than having it be my personal war on the library wording?

Here view is \libconcept'd, so either this is wrong or the uses elsewhere should be \libconcept'd as well. Also, should uses like this be changed to "\libconcept{view} type"s?