[2019-07 LWG Motion 11] P1754R1 Rename concepts to standard_case for C++20

[jensmaurer]

[CaseyCarter]

The proposal directs the Editor to "change namespace view to namespace views (13 occurrences)." in [ranges.syn]. For the final such occurrence, this produces:

namespace std {
  namespace views = ranges::view;

  [...]
}

which is ill-formed since there's no longer a namespace ranges::view. The intent of the paper is that this line change to namespace views = ranges::views; - we intend to change the name of both the ranges::view namespace and its alias in std to views.

Note that #3027 adds some declarations to the namespace std::ranges::view; these should also be changed to std::ranges::views for consistency.

[CaseyCarter]

The proposal inadvertently omits the ForwardRange concept defined in [ranges.syn]. We'd like to rename ForwardRange to forward_range, which is obviously consistent with the renamings of the remaining XXXRange concepts, but it is a stretch to call that renaming Editorial.

Should I submit a library issue for ForwardRange, or might we consider this renaming in-line with the direction given by LEWG if I can get a signoff from LEWG Chair and/or LWG Chair?

EDIT: Herb has reminded me that we added some general directions to the Editor in P1754R1:

Instruct the editors to rename any new concepts to standard_case and follow the naming convention adopted by LEWG described in the second, third, and fourth bullets in section 2.

intending to give the Editor freedom to rename e.g. ThreeWayComparable and ThreeWayComparableWith from P1614 to three_way_comparable and three_way_comparable_with and FloatingPoint from P631 to floating_point. ForwardRange isn't a "new concept", but I think the intent of the proposal as approved by WG21 is clear.

[jwakely]

I think the intent is clear, the editor should rename it.

[jwakely]

But we've agreed to do all such renaming in a single change after applying individual motions, not piecemeal.

[burblebee]

But we've agreed to do all such renaming in a single change after applying individual motions, not piecemeal.

Ah, did not know this. I'm working off of what's in master - I will commit that for review, then will revisit with another commit after the motions are applied to take care of the new concepts - I can make that 2nd commit a "Fixup" so that Richard knows to squash it. If folks can send me a list of what additional concepts were added with these motions that would be a huge help.

[jwakely]

Once all the other motions have been merged to master you can find them with:

git grep 'libconcept{[[:upper:]]'

[burblebee]

Just to make sure I'm doing this correctly, in ranges.tex around line 1149 becomes:

  template<input_or_output_iterator I, sentinel_for<I> S = I, subrange_kind K =
      sized_sentinel_for<S, I> ? subrange_kind::sized : subrange_kind::unsized>
    requires (K == subrange_kind::sized || !sized_sentinel_for<S, I>)
  class subrange : public view_interface<subrange<I, S, K>> {

Right?

[jensmaurer]

Looks reasonable to me, but @CaseyCarter should have an opinion here.

[burblebee]

The biggest problem I'm having with this motion, is that these names are used all over as template parameters (e.g. class Iterator), as old concepts, and as new concepts. Figuring out which one is intended where (e.g. what namespace is this \itemdecl in) is teaching me more about the library than I ever wanted to know. I'm tempted to check in what I have and let @CaseyCarter fix my mistakes :) .

[CaseyCarter]

I'm tempted to check in what I have and let @CaseyCarter fix my mistakes :)

Feel free to assign this motion to me, or to make a branch with what you have and I'll finish it up. "Change these names to these names" is wonderfully simple wording to review, but I'm well aware that we dumped a ton of work on the editors to determine which uses of the source names are uses of the concepts and which are not.