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

Bubke Marco Marco.Bubke at theqtcompany.com
Sat Dec 5 01:57:23 CET 2015

On December 5, 2015 01:43:40 André Pönitz <apoenitz at t-online.de> wrote:

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

Oswald and I spoke about using the clang code model to provide the information to gerrit too. It should be not that hard.

But you have to import the code in the IDE anyway because of the missing context.  For non trivial change review the calling context is far to important to be ignored. A html code browser could change that but we don't have one in gerrit. 

> 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'
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone 

More information about the Development mailing list