(cc'ing sg20 because I am worried about teaching this)

On 17.06.19 07:22, Herb Sutter via Lib-Ext wrote:
> FYI, the attached paper will be in the pre-Cologne mailing. It proposes renaming all library concept names to standard_case for C++20 (renaming only, no semantic change). The coauthors include all of the main proposers of the directly related C++20 features: C++20 Concepts and C++20 Ranges.
>
> Here is a copy of the abstract:
>
> Before C++20, standard identifiers have always used standard_case, without exception. However, current draft C++20 creates a new inconsistency by making concept names use PascalCase. Importantly, the standard's consistent use of standard_case has always made it possible for programmers to create a clear delineation between standard names and domain-specific names, by using PascalCase for domain-specific names. The current draft C++20 PascalCase naming scheme for library concepts breaks that by doing a land grab into that swamp, making it murkier than before. The ambiguity is more than just a naming clash -- it is about the standard style now conflicting with styles that it didn't conflict with before, which is a readability problem, a mental-model-compartmentalization problem, and a whole host of other problems.


Pro:
I do not think that it is problematic to change the style at this point.
I do think there is benefit to having a consistent style in the standard
library.

Con:
I don't agree that standard library style(s) needs to be distinct from
user library styles. If anything I would encourage people to adopt the
*same* style(s) as in the standard library (for consistency in the
language overall). In any case there are so many differenft user styles
that this can hardly be made a criterium, the solution to this is and
always has been namespaces.

However, IMHO the most problematic aspect is the concrete wording of the
proposal:

  * things are called `_type` that aren't types... o_O
  * some concepts have `_type` suffix, others don't
  * some concepts have `has_` prefix, others don't
  * some concepts are visually very close to other names, e.g.
std::constructible, std::is_constructible, std::is_constructible_v…

This all results in concepts now maybe being more "consistent" in style
with the rest of std, but a lot more inconsistent within themselves.
This will be very hard to teach to people.

I understand the desire to unify the style, but std is already quite
"full" and having more things that look more alike will only add to the
confusion. There is no good solution to this other than `std2::`, but
since we don't have that we need to rely on naming to bring some order.
Right now I can tell students and aspiring programmers:

  1. `_t` and `_type` implies that something is a type (template)
  2. `_v` implies that something is a variable (template)
  3. PascalCase implies that something is a concept

And, yes, most of the standard library fits neither of these categories,
but in particular the entities that are confusable often do.

I would be fine with replacing PascalCase so

  3. `_concept` or `_c` implies that something is a concept

Having std::is_constructible_c to go with std::is_constructible_v could
be "consistent", but I expect even stronger feelings about this.

In any case the current proposal would break two of the three teaching
rules up there and greatly increase the amount of (possible) confusion.

Best regards,
Hannes