[Development] RFC: more liberal 'auto' rules?

[Knoll Lars]

On 09/12/15 11:19, "Giuseppe D'Angelo" <dangelog at gmail.com> wrote:



>On Wed, Dec 9, 2015 at 11:16 AM, Knoll Lars <Lars.Knoll at theqtcompany.com> wrote:
>> And I’d say it’s about time to stop that particular sub-thread. It’s neither productive nor leading anywhere.

Just for the record here, I was only asking to stop the off topic part of the discussion (about python and who’s right there). Let’s focus on auto in c++ and how we want to use it.

>
>Is there a consensus otherwise about a more liberal use of auto in our
>source code?

I don’t think there is a full consensus. Let me try to summarise where we are, what I think we agree upon and then add my thoughts :)

As a primary goal, auto should be used wherever it increases readability of the code. I think we all agree here. The problem is that there’s dissent in what ‘more readable code’ is in practice. 

I think everybody also agrees one the use cases listed in https://wiki.qt.io/Coding_Conventions#auto_Keyword , so the question now is what additional use cases do most of us agree to? And how to put that into rules, as a listing with 50 entries won’t help anybody.

While I don’t think we should go and implement aaa right now, I would probably be ok with a somewhat broader usage than the current coding conventions imply. 

Marc presented some use cases. Going through those, I don’t think I heard any disagreement about using auto in template, so I think we can probably add that one to our guidelines. 

For loop variables, I don’t think we should require ‘auto’. Using it can be the right thing to do in some cases, esp when using patterns like ‘for(auto item: items)’ , but when looping using integer indices, I still prefer ‘for (int i=...; cond; ++i)’. 

Are these cases something we can agree upon?

Cheers,
Lars