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

Poenitz Andre Andre.Poenitz at theqtcompany.com
Wed Dec 9 14:47:52 CET 2015

Lars wrote:
> I don’t think there is a full consensus. 

Indeed, there isn't.

> 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.

I agree with that so far.

> 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.

Marc's proposal included to *require* use of "auto" in some cases.

I do not agree with that *required* use at all. That's not just because "auto 
is required in templates" would give the AAA supporters suddenly
a big incentive to start writing or converting normal functions to templates 
just because they can use auto freely there, but since I don't believe visible 
types are bad per-se and far less of a "problem" than the AAA faction tries 
to make me believe.

I would accept (and probably use myself) "optional use of auto" for

- *some* template code (e.g. the mentioned 'typename' case)
- references to elements in a collection *with "non-trivial" type*, i.e.
  something that is a template instance, or in deeply nested namespaces.
  (i.e. ok for  std::pair<Foo, Something::Bar>, not ok for 'int' or 'QString')

Marc's *optional* proposal "Optional use of auto: whereever it makes sense. 
Use your own judgement, but remember: fear is a bad advisor." pretty much
opens the door for AAA, as for an AAA supporter "auto" will *always* make

So effectively the proposal consists of two attempts to implement an AAA
policy. That's going way too far in one step.


More information about the Development mailing list