On 19.06.19 15:00, Bjarne Stroustrup wrote:
>
> On 6/19/2019 5:38 AM, Hannes Hauswedell wrote:
>> (cc'ing sg20 because I am worried about teaching this)
>
> A brief experience report: I have taught concepts for about 4 years
> using the same naming style for types and concepts and seen no problems.
> And that was before we have to use the redundant "auto" in the
> simple/natural/etc. notation.

As I said below, my criticism is not having the same style *in general*;
it is that I fear the *particular names* will lead to confusion if not
distinguished from existing names more clearly (because we have so many
similar names in std already) and that there is new inconsistency
introduced within the naming of the con_cepts.
Both *could* be resolved by chosing different names (instead of a
different style) for many of the concepts, however, I think agreeing on
new names will be even more difficult than agreeig on style, because it
is many (smaller) discussions instead of one.

>>
>> 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
>> Link to this post: http://lists.isocpp.org/lib-ext/2019/06/11906.php
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden]
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2019/06/11911.php

-- 
Best regards,
Hannes Hauswedell
Free Software Foundation Europe -- German Team
/blog/
https://blogs.fsfe.org/h2
/microblog/
https://twitter.com/__h2__
/pgp key/
https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc
/pgp fingerprint/
FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF