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.

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.

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

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

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.

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

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

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?

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

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 :) .

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.

@CaseyCarter Please see PR #3099.

Notes/questions/issues:

• In concepts.tex, we have this wording:
  "The \libconcept{boolean} concept specifies the requirements on a type that is usable in Boolean contexts."
  What are "Boolean contexts"? (Note: this was not changed - left as Boolean).
• What about stuff like:
  "of the \tcode{\placeholder{range-impl}} concept"
  should this use \libconcept?
  (show list save/p1)
• What about renaming the placeholder concept names @\placeholdernc{Advanceable}@ and @\placeholdernc{Decrementable}@?
• What about renaming section names to match the renamed concepts? We now have this mapping of section name to concept:

section                          name concept
-----------------------------------------------
alg.req.ind.cmp                  indirectly_comparable
alg.req.ind.copy                 indirectly_copyable_storable
alg.req.ind.move                 indirectly_movable
alg.req.ind.swap                 indirectly_swappable
concept.assignable               assignable_from
concept.commonref                common_reference_with
concept.common                   common_with
concept.constructible            constructible_from
concept.convertibleto            convertible_to
concept.copyconstructible        copy_constructible
concept.defaultconstructible     default_constructible
concept.derivedfrom              derived_from
concept.equalitycomparable       equality_comparable
concept.moveconstructible        move_constructible
concept.regularinvocable         regular_invocable
concept.same                     same_to
concept.stricttotallyordered     totally_ordered
concept.strictweakorder          strict_weak_order
iterator.concept.random.access   random_access_iterator
iterator.concept.sizedsentinel   sized_sentinel_for

• In concepts.tex, we have this wording:
  "The \libconcept{boolean} concept specifies the requirements on a type that is usable in Boolean contexts."
  What are "Boolean contexts"? (Note: this was not changed - left as Boolean).

"Boolean context" is meaningless fluff which unfortunately can easily be conflated with "contextual conversion to bool". "...specifies the requirements on types of expressions used as predicates in other library concepts." would not be great, but is at least meaningful and won't lead readers astray.

• What about stuff like:
  "of the \tcode{\placeholder{range-impl}} concept"
  should this use \libconcept?

To my understanding we do not use \libconcept for exposition-only concepts.

• What about renaming the placeholder concept names @\placeholdernc{Advanceable}@ and @\placeholdernc{Decrementable}@?

It's outside the mandate of the paper, but I'd be in favor of a separate editorial change to make the names of all exposition-only concepts lower-kebab-case for consistency with the lower-snake-casing of the non-exposition-only concept names.

• What about renaming section names to match the renamed concepts? We now have this mapping of section name to concept:

section                          name concept
-----------------------------------------------
alg.req.ind.cmp                  indirectly_comparable
alg.req.ind.copy                 indirectly_copyable_storable

IIRC both indirectly_copyable and indirectly_copyable_storable

alg.req.ind.move                 indirectly_movable

both indirectly_movable and indirectly_movable_storable

alg.req.ind.swap                 indirectly_swappable
concept.assignable               assignable_from
concept.commonref                common_reference_with
concept.common                   common_with
concept.constructible            constructible_from
concept.convertibleto            convertible_to
concept.copyconstructible        copy_constructible
concept.defaultconstructible     default_constructible
concept.derivedfrom              derived_from
concept.equalitycomparable       equality_comparable
concept.moveconstructible        move_constructible
concept.regularinvocable         regular_invocable
concept.same                     same_to

same_as ;)

concept.stricttotallyordered     totally_ordered
concept.strictweakorder          strict_weak_order
iterator.concept.random.access   random_access_iterator
iterator.concept.sizedsentinel   sized_sentinel_for

We ignored this issue in the ingress paper - we did everything possible to minimize the proposal to give as little bikeshed fuel as we could - but probably should not have. I think that [concept.foobar] is still fine now that FooBar is foo_bar, but we should consider updating the stable names for subclauses whose concepts had name changes more extensive than the direct PascalCase to snake_case restyle. I suggest dropping any trailing preposition from the stable name; "with"s and "from"s don't add much and should never be needed for uniqueness. That would look like:

• concept.convertibleto => concept.convertible
• concept.derivedfrom => concept.derived
• concept.stricttotallyordered => concept.totallyordered
  (I suspect the iterator concept stable names are largely irredeemable since the "old" subclauses have the good names.)

What are "Boolean contexts"?

Opened #3112 for this.

What about renaming the placeholder concept names @\placeholdernc{Advanceable}@ and @\placeholdernc{Decrementable}@?

There was a suggestion in #3099 to rename another placeholder, so I combined these with that as a separate commit in motions-2019-07-lwg-11.

• concept.convertibleto => concept.convertible
• concept.derivedfrom => concept.derived
• concept.stricttotallyordered => concept.totallyordered

Done as a separate commit in motions-2019-07-lwg-11.

@burblebee All other motions are now merged, please can you rebase this and finish it? Please reply here if you're working on it and I'll do the same (if you haven't replied when I get back to it, I'll pick this up and finish it, and I don't want us to duplicate work).

I'm working on the rebase now.