> The C++ Committee Members like Herb Sutter have preached "Almost always

> auto" for almost a decade, and so our guidelines seems to oppose that

> C++ guru wisdom.



Thanks! FWIW, my AAA advice from 2013/14 continues to be widely misunderstood in three ways:



1. I've never ruled out concept constraints, and since the beginning of AAA in 2013 I've pointed forward to concept-constrained auto a number of times (see example reference at bottom). As soon as we have concepts, we should write concepts -- that's just a constrained auto. That is,



                auto first = vec.begin();



should naturally be upgraded to



                iterator auto first = vec.begin();



which is still auto, just constrained. In fact, I expect (hope) that this availability of concept constraints on auto variables will bridge much of the remaining disconnect/debate about whether to use auto regularly or not, because it gives people the ability to still express constraints on the type of the variable, while still getting the benefits of auto (generality, consistency, no-conversion guarantee, initialization guarantee, not needing to commit to a concrete type [but see #2], and so on).



2. I don't teach to always deduce a type. There are two forms I've always taught:



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



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



both of which are still auto. So although the first form is great for making code less brittle under maintenance including to avoid introducing silent conversions/temporaries as types change, the second form is still always available (and actively recommended) when it's appropriate to commit to a particular type, and "AAA" has always taught both of these styles.



However, note that the advice to use concepts constraints applies only to the first form, which is deduced. It's not very useful in the second form, which already commits to a concrete type.



3. The "Almost" in "Almost Always Auto" is now largely gone thanks to C++17 guaranteed copy elision -- so these days the idiom should be renamed pretty much "Always Auto," though of course people are as always free to disagree.





> Does anyone have some links of reference for me I can cite



I would suggest these two:

  * My CppCon 2014 talk, starting at 30:00<https://youtu.be/xnqTKD8uD64?t=1807> where the very first point highlighted in the AAA section was point #2 above that there are two forms and AAA does not mean always deducing the type (so I wish people wouldn't forget that there are the two forms, but oh well).
  * My 2013 article GotW #94<https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/> which was the first time I think I talked about AAA.



I think both of them say the things you are asking for. For example, the article mentions concepts in passing, then I wrote in the Q&A in the comment section:



As I wrote on the Reddit thread: Second, a huge amount of the discussion in this thread is of the form "but if we had concepts we would write "Conceptname x = ...;". That's exactly true and I'm one of the ones pushing strongest for that - and it's a reason to use "auto x = ...;" today because it will mean the same thing, namely to deduce the type (not specify it exactly, no conversions, etc.), just adding the ability to check that the deduced type matches the concept. This is a direct (and intended) evolution of declaring with auto per AAA. If you like that, you're in good company, and you should use auto today. Telling people to declare with concrete types today is not at all the same thing and puts you on a different path of committing to concrete types, which is the opposite of "Conceptname x = ...;".



which is what I think you're looking for?



Herb