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

[André Pönitz]

On Fri, Dec 04, 2015 at 06:10:45PM -0500, Matthew Woehlke wrote:
> On 2015-12-04 17:43, André Pönitz wrote:
> > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
> >> Which of these is easier to read? (More importantly, which is easier to
> >> *verify* that it is correct?)
> >>
> >>   for (int i = 0; i < list.size(); ++i)
> >>     foo(list[i]);
> > 
> > Whether the access is correct depends on the type of list, which you don't
> > disclose.
> 
> That's sort of *the point*. I can't tell if the above is correct or not.
> If it used 'auto', I'd know.

You don't know whether operator[] or .at() is the best way to access
by index until you know the type of list. Once you know the type of
list, you also know what the type of i should be. There's no point
in being fuzzy about it unless there is a *significant* advantage
to it (like using 'auto' for iterator types which are mostly line
noise).

> (And it's sort of implied that it *is* wrong. Because, y'know, I see
> loops like the above quite often where, indeed, they do in fact use the
> wrong type. Actually, QList/QVector are about the *only* times the above
> is written correctly without using 'auto'. More often than not, a loop
> like that written against a non-Qt container uses the wrong index type.)

The context of this discussion is the development of Qt. Thank you for
confirming that 'int' is the right thing to use.

> > In any case, this loop follows a well-known pattern.
> 
> It also follows a really *bad* pattern. The count is reevaluated every
> time (well, you hope the compiler will hoist it, but the code says that
> it is). Using type deduction... well, sucks:
> 
>   for (auto i = decltype(list.size()){0}; i < list.size(); ++i)

[
If you care about size() re-evaluation:

    for (int i = 0, n = list.size(); i < n; ++i)
        ... 
]

>   for (auto i : qtIndexRange(list.size())
> >>     foo(list[i]);
> > 
> > In any case, this is an uncommon pattern, using some unknown qtIndexRange()
> > function.
> 
> Really?
> 
>   (Python)

Please stay on topic. The topic was whether to be more 'liberal' with
the use of auto in Qt, written mostly in C++, not Python.
 
> > 
> > The extra level of parantheses makes it harder to parse for
> > humans,introducing an aditional source of errors, which you nicely
> > demonstrated by making the example non-compilable.
> 
> Bah. A decent IDE would have flagged that as soon as I stopped typing.

You are basically assuming that there's no need for you to write sane
code to start with because during your development work you have a
decent IDE to help you out. This assumption is wrong, independent
of the existence of such an IDE.

Since the discussion here is about what to use in Qt, the whole Qt
development workflow matters. A lot of Qt code reading happens on Gerrit
without IDE features at hand. The context there usually just a few lines.
The appropriateness of an expression 'list[x]' is impossible to judge
on Gerrit after applying an 'Almost always auto' policy.

This argument is not restricted to 'auto'. In general, code patterns
that rely completely on IDE support are not beneficial for Qt
development.

> [...]
> >> Which is *really* more meaningful?
> > 
> > The first one.
> 
> Sorry, but I must strongly disagree.

So we agree to disagree. This was a call for comments. We've now 
established the fact that there's no consensus on this matter.

> In fact, you are missing the whole point of 'auto'.

I don't think so.

> By using 'auto' correctly, it's possible to know that the
> type *is correct*, even if you don't know what the type actually *is*.

You are missing the fact that Qt development is not an IDE-only workflow
and does in general not operate on complete translation unit. You also
do not seem to believe that at least some humans need a bit more explicit
context than compilers to efficiently read code.

Andre'