> On Dec 4, 2015, at 8:01 PM, Olivier Goffart <[email protected]> wrote: > > On Friday 4. December 2015 15:39:01 Curtis Mitch wrote: >>> -----Original Message----- >>> From: Development [mailto:[email protected]] On Behalf Of >>> Olivier Goffart >>> Sent: Friday, 4 December 2015 2:25 PM >>> To: [email protected] >>> Subject: Re: [Development] RFC: more liberal 'auto' rules? >>> >>> On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote: >>>> On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote: >>>>> And as an aside, since it has been mentioned in this thread: in >>>>> Python _all_ variables are 'auto'. All. Without exception. Are >>>>> Python programmers more intelligent? Or do they just tolerate more >>>>> pain? :) >>>> >>>> i'd suggest the latter. >>>> no, really. people use external static checkers because the language >>>> lacks the feature. >>>> the lack of static typing is a common feature of scripting languages >>>> and makes them convenient to a degree, but it is an utter nightmare >>>> for any "real" software development. i really wouldn't want to go there. >>> >>> But auto is still staticaly typed. >>> >>> >>> When you have code like >>> >>> foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type())); >>> >>> You don't see any type. >>> >>> This code that use auto is not less readable. Even if you don't know >>> what's the type of bar without looking it up. >>> >>> auto *bar = foo->bar(); >>> bar->setFaz(m_factory->createFaz(bar->type())); >> >> Isn't this kind of a bad example, because there was no type declared/visible >> in the first place? > > Precisely my point! > There is no type visible before and nobody complains. So why should one > suddenly complains there are no types in the second snippet > >> Anyway, if you're going to take the time to move the result of foo->bar() >> onto its own line, why not just declare a type? What benefit does auto give >> here? >> >> I really dislike hiding types behind a generic keyword. > > Because the type is redundent and it's one reason less to make errors: > Using 'int' instead of 'quint64' or 'size_t', or QString instead of > QByteArray > is way to frequent. (and the compiler won't complain)
The compiler will then still not complain if you pass that ‘auto’ variable to a function taking ‘int’ (or QString, if you don’t have NO_CAST_...), will it? So in the end people will still just need to know what they are doing, or, since IDE support is mentioned several times in this thread, use an IDE with stricter warning policy. (The default setting for the Clang code model in Qt Creator is to warn when assigning or comparing 'unsigned int' and ‘int' etc ;) ) > It is also refactoring-proof. Because you might want to change the name of > the type from "FazManager" to "FazHolder", and then you need to touch less > code in your refactoring. On the other hand if you are changing the return value of a function, there will be cases where it would be better if you (and anyone using your function) had to explicitly look at the usages. I do not think that more usage of ‘auto’ will make any code (or refactorings of it) ‘safer’. IMO this is only about convenience and readability. Br, Eike _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
