Thanks Martin for starting this thread, and to everyone for all your feedback.

General comment: I would welcome coauthoring an updated (A)AA post/paper that reflects a broader modern consensus in the C++20 concepts era.

Is there a critical mass of previously-critical people who would be interested in coauthoring such, presumably with the key point of encouraging that the first form below be concept-constrained? Again, the two forms are:

                auto x = expr; // to make the type track, deduce it

                auto x = type{expr}; // to make the type stick, commit to it

... so part of the updated post would be to remind people that "(A)AA is *not* recommending that all types be deduced," there are two forms, both with benefits over the "type x{expr}" form such as the no-implicit-conversion guarantee by construction, the no-uninit guarantee by construction, etc. My guess, at least by default subject to conversations, would be that it would be putting on paper what I said at CppCon 2014 (which included both styles above, whereas the original GotW AAA post didn't lay them out clearly and focused only on the first one) plus encouraging use of concepts for deduced types (really for all deduced types in general, but for auto variable types in particular).

Herb


> -----Original Message-----
> From: Ville Voutilainen <ville.voutilainen_at_gmail.com>
> Sent: Sunday, December 15, 2019 10:51 AM
> To: sg20_at_[hidden]
> Cc: Herb Sutter <hsutter_at_microsoft.com>; Martin Beeger
> <martin.beeger_at_online.de>
> Subject: Re: [SG20] Difficulties in teaching the use of C++20 concepts
>
> On Sun, 15 Dec 2019 at 15:56, Martin Beeger via SG20
> <sg20_at_lists.isocpp.org> wrote:
> > But to sum up regarding the use of auto, a post-C++20 guideline could be (a
> hopefully much more well-formulated and littered with examples version of
> the following):
> >
> > 1. whenever the type of the expression is mentioned on the right hand of a
> statement, just put auto on the left side for brevity instead of repeating
> yourself on the left hand.
> >
> > 2. whenever auto represents a generic value whose type is not known
> locally, look for a fitting named constrained and apply it for the auto
> parameter to ensure semantic correctness of the using code without loss of
> genericity.
> >
> > 3. whenever you develop code and you are not thinking of its correctness in
> terms of concrete types but in form of general concepts, use auto.
> >
> > 4. whenever you write functions, try to think of the problem in you solve as
> a abstract problem and about generic solutions, not only about one for your
> concrete types. Look for an exisisting solution to a general problem.
> >
> > As you apply the last rule to your coding (in line with Sean Parents Better
> Code principles) you will either find an a solution already there, if you don't,
> what you will write will now fall under rule 3, which will in turn then fall
> under rule 2.
> >
> > Is that an accurate representation of what the your AAA (now AA) rule
> intends to achieve and how you would advise in a C++20 world?
> >
> > I as and AAA skeptic can totally get behind this new version.
>
> While I remain an AA/AAA skeptic, the constrained version of it certainly gives
> an intriguing almost-best-of-all-worlds facility that is nicely in-between: it
> allows enforcing concrete types if the programmer so chooses (which
> happens in various cases on API boundaries, it's a "tell me at first chance if I
> didn't get what I expected"), which imho isn't "brittle", it's perhaps "rigid",
> and as a stretch "robust", in contrast with the unfortunate connotations of
> "brittle".
>
> See
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwand
> box.org%2Fpermlink%2F6G5Afjy2m6EO2TMz&amp;data=02%7C01%7Chsutte
> r%40microsoft.com%7C6d5fd900d974461b6aa008d7817695c5%7C72f988bf
> 86f141af91ab2d7cd011db47%7C1%7C0%7C637120218626110328&amp;sda
> ta=pTbyyFmJDe0iU%2FmsQxtC13S3w1TwdsnEvJNvbWWxt8E%3D&amp;reser
> ved=0
>
> tl;dr for those who wish to see it inline:
>
> #include <concepts>
>
> int f() {return 42;}
>
> long g() {return 555L;}
>
> int main()
> {
> std::same_as<int> auto x = f();
> std::same_as<long> auto y = g();
> }
>
> No conversions. No blind duck typing either. If I change the return type of f()
> to be something else than int, I get a compiler error exactly where I want it, no
> later, and certainly not at run-time when I try to figure out what on earth got
> instantiated with a type that wasn't what I thought it was.