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

[Matthew Woehlke]

On 2015-12-04 19:44, André Pönitz wrote:
> 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).

Then there is also no significant advantage to writing an explicit type
rather than inferring it. You can't have it both ways.

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

The correct *actual* type is 'int'. Whether Qt should encourage bad
programming practices by writing explicitly typed index loops, that are
more often wrong than otherwise outside of Qt containers, is a different
question.

> [
> If you care about size() re-evaluation:
> 
>     for (int i = 0, n = list.size(); i < n; ++i)
>         ... 
> ]

...and now 'n' is mutable, opening the door to bugs due to accidental
modification thereof. (As is 'i', for that matter; a range-based for
over an index enumerator¹ allows you to make that const also.)

(¹ English-language sense, not C++ "enum".)

> On Fri, Dec 04, 2015 at 06:10:45PM -0500, Matthew Woehlke wrote:
>> On 2015-12-04 17:43, André Pönitz wrote:
>>> 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 point is that index enumerators are *not* an unknown programming
construct, as you assert.

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

Uh... no? The point is your bashing a particular construct because it
can be mistyped *in the pitiful excuse for a text editor with which I'm
writing this message*, but will be easily and immediately noticed in a
decent editor, is silly.

Or, maybe we should stop using C++ because of all those pesky ';'s one
has to remember at the end of every statement.

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

Well, then, I guess you can't judge if 'int' is the correct type for
'x', either. Sounds like an excellent reason *to* use 'auto'!!!

Anyway, if you're going to bash a feature, you need to find a better
reason than obvious compile errors that are flagged in the user's
editor. Because the chances of those ever being committed locally, much
less merged (or indeed, even lasting more than a few seconds) are
virtually nil.

-- 
Matthew