Date: Wed, 19 Jun 2019 19:15:07 +0200
On Wed, 19 Jun 2019 at 16:59, Gabriel Dos Reis via Ext <ext_at_[hidden]>
wrote:
>
> - 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.
>
+1
JC
>
>
> *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]>:
>
> (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]
> 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.
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2019/06/10310.php
>
wrote:
>
> - 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.
>
+1
JC
>
>
> *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]>:
>
> (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]
> 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.
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2019/06/10310.php
>
Received on 2019-06-19 12:17:11