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

[Curtis Mitch]

> -----Original Message-----
> From: Development [mailto:development-bounces at qt-project.org] On Behalf Of
> Olivier Goffart
> Sent: Friday, 4 December 2015 2:25 PM
> To: development at qt-project.org
> 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?

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