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

Marc Mutz marc.mutz at kdab.com
Tue Dec 8 20:43:53 CET 2015

On Tuesday 08 December 2015 15:52:06 Oswald Buddenhagen wrote:
> On Mon, Dec 07, 2015 at 03:39:25PM +0100, Marc Mutz wrote:
> > OK, last try:
> > 
> > - auto everywhere in C++ means that the type of the rhs defines the
> > type of the variable
> it starts with the fact that you didn't specify that you mean just local
> variables - it's your unstated assumption.

Wrong. This whole thread was never about anything but auto variables:

On Thursday 03 December 2015 19:49:46 Marc Mutz wrote:
> The wiki[1] currently contains some rules for how to use automatic type 
> deduction for variables (Q_C_AUTO_TYPE) that are very restrictive.

> your triple emphasis that
> it's not necessary *anywhere* in python implied that you do indeed mean
> more than just locals.

Only for someone who chimes in on a side-line without having read the thread's 
first mail...

 > > - each variable is still statically typed.
> > - In particular, you cannot assign, say, an int to the variable and later
> > 
> >   assign it a string.
> > 
> > - in Python, variables are declared with 'var' (IIRC)
> well, wrong. in python, you don't explicitly declare variables *at all*.
> you only ever assign them. just so.
> "var" is c#'s auto. or js' variant (aka c#'s "dynamic"). these are
> actually the two opposite concepts, so maybe you're the one who's
> confused? ;)

I don't *care* whether it's "var" or no keyword or JS variant or _whatever_. I 
said it's about the omission of the _type name_. You deliberately 
misunderstand and drag this subthread on and then zoom in on the first slip of 
mine. That's trolling at it's worst.

> > - the simiarity with C++ auto is that no type name is visible
> > 
> >   - this is what I was referring to
> > 
> > - the difference to C++ (auto or not) is that in Python, the variable is
> > weakly
> > 
> >   typed / dynamically typed / duck-typed, however you may want to call
> >   it.
> > 
> > - in particular, the variable can hold an integer first, then a string,
> > and
> > 
> >   later an object of class type. Conversely, any type can be held in any
> >   variable.
> >   
> >   - this is orthogonal to the omission of the type name, which C++ auto
> >   and
> >   
> >     the whole thread is all about, thus *completely irrelevant* to the
> >     discussion.
> no, it's actually not orthogonal, and that's the whole point. in the
> generic case, it's impossible to implement "auto *everywhere*" without
> going dynamic. this is such a fundamental property of the language, that
> it is patently absurd to infer anything from it for statically typed
> languages, especially if you look at just one particular case.
> >     I, indeed, have no idea why you ride that particular horse so
> >     vehemently.
> so let's state the purpose even more clearly: i'm giving you a lesson.
> you tried to prove your point with a bogus analogy, and screwed up even
> more by underestimating the downsides of the paradigm you were comparing
> to. just admit it, and we're done - i'm actually convinced by your
> non-bogus arguments.

I should have known.... tr(Besserwisser).


Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts

More information about the Development mailing list