[ranges] Parameter of range refinement should be named R

[JohelEGP]

Following the practice of iterator concepts, range refinements should name their to-be-range parameter R instead of T. A handful of exposition-only concepts and output_range<R, T> (inevitably) already do.

[jensmaurer]

Could you please be a little more specific? Sometimes, it's actually a "view" that is called V.

[JohelEGP]

Right. I mean that the definition of concepts that refine range should name its parameter that will eventually be checked as range<T> so that it looks like range<R> instead.

The following already use R that way:

  template<class R, class T>
    concept output_range =
  template<class R>
    concept @\exposconcept{tiny-range}@ =

The following should change T to be R, similarly changing their specification to use R models C rather than T models C.

  template<class T>
    concept range =
  template<class T>
    concept sized_range =
  template<class T>
    concept view =
  template<class T>
    concept input_range =
  template<class T>
    concept forward_range =
  template<class T>
    concept bidirectional_range =
  template<class T>
    concept random_access_range =
  template<class T>
    concept contiguous_range =
  template<class T>
    concept common_range =
  template<class T>
    concept viewable_range =
template<class T>
  concept @\defexposconcept{forwarding-range}@ =
template<class R>
  concept @\defexposconcept{simple-view}@ =

Right now, the iterator concepts mostly use I (sometimes In or Out), whereas the range concepts mostly use T.

[JohelEGP]

Could you please be a little more specific? Sometimes, it's actually a "view" that is called V.

Indeed, the range adaptors use V for their view parameter. Except for the most recent additions that used R instead, creating inconsistency.

[jensmaurer]

@CaseyCarter , are you ok with the suggested T -> R rename?

[CaseyCarter]

I'm ambivalent. Pre-concepts, we used the names of template parameters to indicate requirements that the template argument must fulfill. Post-concepts, we generally pick a name that's short but still suggestive of the requirements that are explicit in a type-constraint or requires-clause (Range R, forward_iterator I). Neither of those motivations apply to the template parameters for concepts, so I'm not sure it makes to use something other than the generic T for "type" to name a type parameter for a concept, for example.

Admittedly we're inconsistent about this in the existing library specification - I don't think anyone's given it much thought. In any case, I'm neither strongly in favor of nor strongly opposed to the change.

EDIT:

the definition of concepts that refine range should name its parameter that will eventually be checked as range<T> so that it looks like range<R> instead

This seems arbitrary to me. In:

template <class T>
concept X = Meow<T> && Woof<T> && Buzz<T>;

Should we change T to M, W, or B? Should the answer be different for:

template <class T>
concept X = Meow<T> && requires { /* ... */ };

or

template <class T>
concept X = requires { /* ... */ };

?

[JohelEGP]

template <class T>
concept X = Meow<T> && Woof<T> && Buzz<T>;

Such an aggregate concept could use T, or if the context hints at some most important refinement, the first capital letter of such a concept. The PR of ericniebler/stl2#623 would use R, as would its current form.

template <class T>
concept X = Meow<T> && requires { /* ... */ };

M, at least in the context of the range refinements.

template <class T>
concept X = requires { /* ... */ };

T's fine.

[jwakely]

I don't see any compelling reason to use M in the example above. It's not ill-formed or undefined to substitute a type that doesn't satisfy Meow, it just means the concept isn't satisfied, i.e. evaluates to false.

In fact, I'd say using T consistently is better because it doesn't make me pause and wonder if there's some deeper meaning to the choice of letter.

[jensmaurer]

Editorial meeting: Concepts are predicates. The name should not presuppose the outcome of the check. Thus, use "T" in concept definitions.