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

Oswald Buddenhagen oswald.buddenhagen at theqtcompany.com
Tue Dec 8 15:52:06 CET 2015

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. your triple emphasis that
it's not necessary *anywhere* in python implied that you do indeed mean
more than just locals.

> - 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? ;)

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

More information about the Development mailing list