* Here, std already is different, which we taught for years.
So the new rule would help me NOT to explain why std symbols now suddenly have camel case.
So I don't agree that this is harder to teach.

+1.

From: Ext <ext-bounces_at_[hidden]> On Behalf Of Nico Josuttis
Sent: Wednesday, June 19, 2019 3:30 AM
To: C++ Library Evolution Working Group <lib-ext_at_[hidden]>; Hannes Hauswedell <h2_at_[hidden]>; Evolution Working Group mailing list <ext_at_[hidden]>; Library Working Group <lib_at_[hidden]>
Cc: sg20_at_[hidden]
Subject: Re: [isocpp-ext] [isocpp-lib-ext] P1754R0: Rename concepts to standard_case for C++20, while we still can

According to my experience the most common project rule is
- objects/values start lower case
- types start upper case

Here, std already is different, which we taught for years.
So the new rule would help me NOT to explain why std symbols now suddenly have camel case.
So I don't agree that this is harder to teach.

But, can somebody elaborate on the following, please :
AFAIK, we get the ability to use auto as function parameters:
foo(auto x)
Do we also allow to use concepts here:
foo(myconcept x)
If not I bet we will get it later.

HERE I really would like to be able to see that a standard concept is used
So
foo(myconcept x)
and
foo (string x)
should be able to be seen different.
For that reason I highly recommend a common prefix:
foo(c_myconcept x)
(or a suffix, but better a prefix):
foo(myconcept_concept x)

This also applies if namespaces are used.

Or in other words :
IDE's and editors should be able to handle concepts differently from types.
If not, we create a lot of burden to programmers.
because we need different dyntax highlighting if concepts instead of types are used.



Am 19. Juni 2019 11:38:14 OEZ schrieb Hannes Hauswedell <h2_at_[hidden]<mailto:h2_at_[hidden]>>:

(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

________________________________

Lib-Ext mailing list
Lib-Ext_at_[hidden]cpp.org<mailto:Lib-Ext_at_[hidden]>
Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/lib-ext<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Flib-ext&data=02%7C01%7Cgdr%40microsoft.com%7C115c641b5ea8498203ac08d6f4a1685f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636965371422967208&sdata=i%2FYz%2BMc76%2FSrocjkUObUmmI3FAMcd2B%2Bvjz92%2BaR9gA%3D&reserved=0>
Link to this post: http://lists.isocpp.org/lib-ext/2019/06/11906.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Flib-ext%2F2019%2F06%2F11906.php&data=02%7C01%7Cgdr%40microsoft.com%7C115c641b5ea8498203ac08d6f4a1685f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636965371422977202&sdata=MEuVshD4w18CbjT237bR9cwSeF6TLOJQOZePpRKs6dY%3D&reserved=0>

________________________________
Diese Nachricht wurde von meinem Fairphone2 mit K-9 Mail gesendet.