www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D's auto keyword

reply Justin Johansson <no spam.com> writes:
Happy New Year 2010 Everybody.

Having resumed C++ nationality for the last few months, I kind of miss D's auto
keyword.

I am wondering, though, from an OO/polymorphism perspective, and UML and sound
software engineering perspective as well, what does D's auto keyword buy you
except (perhaps) laziness (in keystrokes)?

Sure the auto variable decl allows the declared var to take on the static type
(i.e. as inferred by the compiler), but the programmer still has to know (in
subsequent method invocations applied to the auto var) just what methods are
valid for the statically inferred var type being the subject of the auto decl.

In some ways, as I said above, I miss "D auto" in C++; but then again, when I
explicitly write the exact same type as the function return signature says, I
feel more in control of my software design.

In an ideal world, which in of course such utopia does not really exist,  a
pure OO model may well be that of single inheritance, and therefore all methods
would, or could, be forced into a base class and hence, for object/polymorphic
types D'auto keyword would not prove much advantage.

(Pray, let's not get into fragile base class discussions.)

At the end of the day, I'm not sure if D's auto keyword really helps to make my
code more readable to others (alla programming-in-the-large) or if it just
helps me with typing shortcuts (alla programming-in-the-small).

btw. 20 years ago I thought the Forth language was fantastic.  Then later I
learned the difference between programming-in-the-small and
programming-in-the-large.

Of course, Forth still hold fond memories for me .. but today I'd still rather
stick to C++.

In writing this NG post, I was wondering about a subject line like "what's the
best thing about D", but then my love/hate relationship with D's auto keyword
really got me.

btw. Do any other languages have an "auto" var idiom?  I don't remember Scala
having such (and it's really modern), though perhaps my memory lapses.

Cheers again,

Justin Johansson
Jan 13 2010
next sibling parent reply Justin Johansson <no spam.com> writes:
And sorry for saying btw twice in the same post.
And sorry for posting this apology.
JJ
Jan 13 2010
parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Wed, 13 Jan 2010 17:52:41 +0100, Justin Johansson <no spam.com> wrote:


 And sorry for saying btw twice in the same post.
 And sorry for posting this apology.
 JJ


You are not forgiven. Post moar apologies. :p

-- 
Simen
Jan 13 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Justin Johansson:


 I am wondering, though, from an OO/polymorphism perspective, and UML and sound
software engineering perspective as well, what does D's auto keyword buy you
except (perhaps) laziness (in keystrokes)?


In functional/generic code you sometimes end having very complex types (what
comes out of a lazy chain of a lazy filtering of a lazy mapping of some lazy
generator, for example), in such situation having a bit of type inference saves
you a lot. And then you give this monster to other templated functions, that
are able to work with any iterable (Range, in Phobos2), so there's no a huge
type signature anywhere.



 In some ways, as I said above, I miss "D auto" in C++; but then again, when I
explicitly write the exact same type as the function return signature says, I
feel more in control of my software design.


Yes, an over-usage of "auto" makes the code a bit less self-descriptive (this
sometimes can be negative, so as with most features of a language you don't
have to abuse it), but if you use dynamic languages you get used to that :-)



btw. 20 years ago I thought the Forth language was fantastic.  Then later I
learned the difference between programming-in-the-small and
programming-in-the-large.<


The name of the recently developed Scala language means scalable language. It
recognizes the need for both scaling up (what you are talking about here, that
Java and especially Ada give you) and scaling down (what dynamic languages like
Python sometimes give you). Both things are important, because a programmer has
to write programs of all sizes, not just huge ones and not just small ones.



I was wondering about a subject line like "what's the best thing about D",<


I don't know. Probably the community around it. Walter is a bit like a bear
sometimes, but still the community grown around his language is alive, despite
its small size. Andrei has improved it some more.



 btw. Do any other languages have an "auto" var idiom?  I don't remember Scala
having such (and it's really modern), though perhaps my memory lapses.



something similar, a local form of simple type inference.

Bye,
bearophile
Jan 13 2010
parent Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 13 de enero a las 12:01 me escribiste:

 btw. Do any other languages have an "auto" var idiom?  I don't remember Scala
having such (and it's really modern), though perhaps my memory lapses.


 

something similar, a local form of simple type inference.


Go allows var and an even shorter alternative, the := operator:

var x = 1   <===>   x := 1

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Me encanta el éxito; por eso prefiero el estado de progreso constante,
con la meta al frente y no atrás.
	-- Ricardo Vaporeso. Punta del Este, Enero de 1918.
Jan 13 2010
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Justin Johansson (no spam.com)'s article

 Happy New Year 2010 Everybody.
 Having resumed C++ nationality for the last few months, I kind of miss D's auto


keyword.

 I am wondering, though, from an OO/polymorphism perspective, and UML and sound


software engineering perspective as well, what does D's auto keyword buy you
except (perhaps) laziness (in keystrokes)?

 Sure the auto variable decl allows the declared var to take on the static type


(i.e. as inferred by the compiler), but the programmer still has to know (in
subsequent method invocations applied to the auto var) just what methods are
valid
for the statically inferred var type being the subject of the auto decl.

 In some ways, as I said above, I miss "D auto" in C++; but then again, when I


explicitly write the exact same type as the function return signature says, I
feel
more in control of my software design.

 In an ideal world, which in of course such utopia does not really exist,  a
pure


OO model may well be that of single inheritance, and therefore all methods
would,
or could, be forced into a base class and hence, for object/polymorphic types
D'auto keyword would not prove much advantage.

 (Pray, let's not get into fragile base class discussions.)
 At the end of the day, I'm not sure if D's auto keyword really helps to make my


code more readable to others (alla programming-in-the-large) or if it just helps
me with typing shortcuts (alla programming-in-the-small).

 btw. 20 years ago I thought the Forth language was fantastic.  Then later I


learned the difference between programming-in-the-small and
programming-in-the-large.

 Of course, Forth still hold fond memories for me .. but today I'd still rather


stick to C++.

 In writing this NG post, I was wondering about a subject line like "what's the


best thing about D", but then my love/hate relationship with D's auto keyword
really got me.

 btw. Do any other languages have an "auto" var idiom?  I don't remember Scala


having such (and it's really modern), though perhaps my memory lapses.

 Cheers again,
 Justin Johansson


One underappreciated thing auto gives is DRY for types.  It makes it easier to
change the type of some object in the place where it's initially decided,
because
those changes will automagically be propagated to everything that uses that
object, as long as the new type supports the same compile-time interface as the
old type.
Jan 13 2010
next sibling parent =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/13/2010 06:19 PM, dsimcha wrote:

 == Quote from Justin Johansson (no spam.com)'s article

 Happy New Year 2010 Everybody.
 Having resumed C++ nationality for the last few months, I kind of miss D's auto


 keyword.

 I am wondering, though, from an OO/polymorphism perspective, and UML and sound


 software engineering perspective as well, what does D's auto keyword buy you
 except (perhaps) laziness (in keystrokes)?

 Sure the auto variable decl allows the declared var to take on the static type


 (i.e. as inferred by the compiler), but the programmer still has to know (in
 subsequent method invocations applied to the auto var) just what methods are
valid
 for the statically inferred var type being the subject of the auto decl.

 In some ways, as I said above, I miss "D auto" in C++; but then again, when I


 explicitly write the exact same type as the function return signature says, I
feel
 more in control of my software design.

 In an ideal world, which in of course such utopia does not really exist,  a
pure


 OO model may well be that of single inheritance, and therefore all methods
would,
 or could, be forced into a base class and hence, for object/polymorphic types
 D'auto keyword would not prove much advantage.

 (Pray, let's not get into fragile base class discussions.)
 At the end of the day, I'm not sure if D's auto keyword really helps to make my


 code more readable to others (alla programming-in-the-large) or if it just
helps
 me with typing shortcuts (alla programming-in-the-small).

 btw. 20 years ago I thought the Forth language was fantastic.  Then later I


 learned the difference between programming-in-the-small and
programming-in-the-large.

 Of course, Forth still hold fond memories for me .. but today I'd still rather


 stick to C++.

 In writing this NG post, I was wondering about a subject line like "what's the


 best thing about D", but then my love/hate relationship with D's auto keyword
 really got me.

 btw. Do any other languages have an "auto" var idiom?  I don't remember Scala


 having such (and it's really modern), though perhaps my memory lapses.

 Cheers again,
 Justin Johansson


 One underappreciated thing auto gives is DRY for types.  It makes it easier to
 change the type of some object in the place where it's initially decided,
because
 those changes will automagically be propagated to everything that uses that
 object, as long as the new type supports the same compile-time interface as the
 old type.


This!

Makes some refactoring tasks ridiculously smooth.
Jan 13 2010
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:

 One underappreciated thing auto gives is DRY for types.  It makes it easier to
 change the type of some object in the place where it's initially decided,
because
 those changes will automagically be propagated to everything that uses that
 object, as long as the new type supports the same compile-time interface as the
 old type.



I consider that a *major* advantage to auto.
Jan 13 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Justin Johansson wrote:

 Happy New Year 2010 Everybody.
 
 Having resumed C++ nationality for the last few months, I kind of miss D's
auto keyword.
 
 I am wondering, though, from an OO/polymorphism perspective, and UML and sound
software engineering perspective as well, what does D's auto keyword buy you
except (perhaps) laziness (in keystrokes)?
 
 Sure the auto variable decl allows the declared var to take on the static type
(i.e. as inferred by the compiler), but the programmer still has to know (in
subsequent method invocations applied to the auto var) just what methods are
valid for the statically inferred var type being the subject of the auto decl.
 
 In some ways, as I said above, I miss "D auto" in C++; but then again, when I
explicitly write the exact same type as the function return signature says, I
feel more in control of my software design.
 
 In an ideal world, which in of course such utopia does not really exist,  a
pure OO model may well be that of single inheritance, and therefore all methods
would, or could, be forced into a base class and hence, for object/polymorphic
types D'auto keyword would not prove much advantage.
 
 (Pray, let's not get into fragile base class discussions.)
 
 At the end of the day, I'm not sure if D's auto keyword really helps to make
my code more readable to others (alla programming-in-the-large) or if it just
helps me with typing shortcuts (alla programming-in-the-small).
 
 btw. 20 years ago I thought the Forth language was fantastic.  Then later I
learned the difference between programming-in-the-small and
programming-in-the-large.
 
 Of course, Forth still hold fond memories for me .. but today I'd still rather
stick to C++.
 
 In writing this NG post, I was wondering about a subject line like "what's the
best thing about D", but then my love/hate relationship with D's auto keyword
really got me.
 
 btw. Do any other languages have an "auto" var idiom?  I don't remember Scala
having such (and it's really modern), though perhaps my memory lapses.
 
 Cheers again,
 
 Justin Johansson


"auto" is huge and has a lot to do with programming-at-large. Explicit 
types are to generic code as bad as hardcoded magic numbers to regular code.

Andrei
Jan 13 2010
prev sibling next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Justin Johansson wrote:

 Do any other languages have an "auto" var idiom?


C++0x has:

   http://www2.research.att.com/~bs/C++0xFAQ.html#auto

Ali
Jan 13 2010
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
On 01/13/2010 05:49 PM, Justin Johansson wrote:

 Happy New Year 2010 Everybody.

 Having resumed C++ nationality for the last few months, I kind of miss D's
auto keyword.

 I am wondering, though, from an OO/polymorphism perspective, and UML and sound
software engineering perspective as well, what does D's auto keyword buy you
except (perhaps) laziness (in keystrokes)?


A lot:

auto foo = bar(2);
auto baz = grok(foo);

No types to be seen here (aside from the literal 2) so you can:
1. rename the type whatever bar() returns without ripple effects through 
this code
2. substitute the type itself for another type that obeys the same 
structural interface.

In a way, it's like not using magic numbers only applied to types :) The 
benefits are not limited too but more pronounced in templated code.



 Sure the auto variable decl allows the declared var to take on the static type
(i.e. as inferred by the compiler), but the programmer still has to know (in
subsequent method invocations applied to the auto var) just what methods are
valid for the statically inferred var type being the subject of the auto decl.

 In some ways, as I said above, I miss "D auto" in C++; but then again, when I
explicitly write the exact same type as the function return signature says, I
feel more in control of my software design.


Depends on how this is used I think, see also below.



 In an ideal world, which in of course such utopia does not really exist,  a
pure OO model may well be that of single inheritance, and therefore all methods
would, or could, be forced into a base class and hence, for object/polymorphic
types D'auto keyword would not prove much advantage.

 (Pray, let's not get into fragile base class discussions.)

 At the end of the day, I'm not sure if D's auto keyword really helps to make
my code more readable to others (alla programming-in-the-large) or if it just
helps me with typing shortcuts (alla programming-in-the-small).

 btw. 20 years ago I thought the Forth language was fantastic.  Then later I
learned the difference between programming-in-the-small and
programming-in-the-large.

 Of course, Forth still hold fond memories for me .. but today I'd still rather
stick to C++.

 In writing this NG post, I was wondering about a subject line like "what's the
best thing about D", but then my love/hate relationship with D's auto keyword
really got me.

 btw. Do any other languages have an "auto" var idiom?  I don't remember Scala
having such (and it's really modern), though perhaps my memory lapses.

 Cheers again,

 Justin Johansson


All ML derived languages do this much more extensively and they even 

mean the same thing. The nice thing with those languages is that if you 
code in Visual Studio, you only have to hover above the variabele and 
the type pops up. Most IDE's have this btw, including descent, so that 
takes away the concern of having to remember the flow of types inferred.
Jan 13 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Wed, 13 Jan 2010 20:22:02 +0100, Lutger wrote:


 On 01/13/2010 05:49 PM, Justin Johansson wrote:

 Happy New Year 2010 Everybody.

 Having resumed C++ nationality for the last few months, I kind of miss
 D's auto keyword.

 I am wondering, though, from an OO/polymorphism perspective, and UML
 and sound software engineering perspective as well, what does D's auto
 keyword buy you except (perhaps) laziness (in keystrokes)?


 
 A lot:
 
 No types to be seen here (aside from the literal 2) so you can: 1.
 rename the type whatever bar() returns without ripple effects through
 this code
 2. substitute the type itself for another type that obeys the same
 structural interface.
 
 In a way, it's like not using magic numbers only applied to types :) The
 benefits are not limited too but more pronounced in templated code.


The main benefit IMO is that you don't need to repeat things twice.

sadklaskdjlaj<aslfkjals, asdkjasldjw<asldjalsdm, asdjslk>> foo = new 
sadklaskdjlaj<aslfkjals, asdkjasldjw<asldjalsdm, asdjslk>>(); // no thanks

Repetition happens every time one uses advanced data structures like 
lists, hashes, tuples etc. In cases like


 
 auto foo = bar(2);
 auto baz = grok(foo);


I would actually explicitly write to type some times to document things 
better.


 All ML derived languages do this much more extensively and they even

 mean the same thing. The nice thing with those languages is that if you
 code in Visual Studio, you only have to hover above the variabele and
 the type pops up. Most IDE's have this btw, including descent, so that
 takes away the concern of having to remember the flow of types inferred.


A tru 1337 koder uses vim or emacs, both of which suck at semantic 
analysis :)
Jan 13 2010
parent Lutger <lutger.blijdestijn gmail.com> writes:
On 01/13/2010 08:46 PM, retard wrote:

 Wed, 13 Jan 2010 20:22:02 +0100, Lutger wrote:


 On 01/13/2010 05:49 PM, Justin Johansson wrote:

 Happy New Year 2010 Everybody.

 Having resumed C++ nationality for the last few months, I kind of miss
 D's auto keyword.

 I am wondering, though, from an OO/polymorphism perspective, and UML
 and sound software engineering perspective as well, what does D's auto
 keyword buy you except (perhaps) laziness (in keystrokes)?


 A lot:

 No types to be seen here (aside from the literal 2) so you can: 1.
 rename the type whatever bar() returns without ripple effects through
 this code
 2. substitute the type itself for another type that obeys the same
 structural interface.

 In a way, it's like not using magic numbers only applied to types :) The
 benefits are not limited too but more pronounced in templated code.


 The main benefit IMO is that you don't need to repeat things twice.

 sadklaskdjlaj<aslfkjals, asdkjasldjw<asldjalsdm, asdjslk>>  foo = new
 sadklaskdjlaj<aslfkjals, asdkjasldjw<asldjalsdm, asdjslk>>(); // no thanks

 Repetition happens every time one uses advanced data structures like
 lists, hashes, tuples etc. In cases like


 auto foo = bar(2);
 auto baz = grok(foo);


 I would actually explicitly write to type some times to document things
 better.


Well I usually don't use names such as foo, bar and baz in production 
code ;) (I suck at naming and have recently started to make long names). 
I get your point but would consider that kind of repetition the least of 
the benefits, since there is no big downside here to copy & paste away.


 All ML derived languages do this much more extensively and they even

 mean the same thing. The nice thing with those languages is that if you
 code in Visual Studio, you only have to hover above the variabele and
 the type pops up. Most IDE's have this btw, including descent, so that
 takes away the concern of having to remember the flow of types inferred.


 A tru 1337 koder uses vim or emacs, both of which suck at semantic
 analysis :)


Then again, such a koder don't need no pedantic type declarations for 
reminders.
Jan 13 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Lutger" <lutger.blijdestijn gmail.com> wrote in message 
news:hil6gr$2hmn$1 digitalmars.com...

 All ML derived languages do this much more extensively and they even don't 

 same thing. The nice thing with those languages is that if you code in 
 Visual Studio, you only have to hover above the variabele and the type 
 pops up. Most IDE's have this btw, including descent, so that takes away 
 the concern of having to remember the flow of types inferred.


Doesn't "Dim" (without an "As" clause) declare a variant rather than a 
compile-time-inferred static type? Or did that change in VB.NET?
Jan 13 2010
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
On 01/13/2010 10:22 PM, Nick Sabalausky wrote:

 "Lutger"<lutger.blijdestijn gmail.com>  wrote in message
 news:hil6gr$2hmn$1 digitalmars.com...

 All ML derived languages do this much more extensively and they even don't

 same thing. The nice thing with those languages is that if you code in
 Visual Studio, you only have to hover above the variabele and the type
 pops up. Most IDE's have this btw, including descent, so that takes away
 the concern of having to remember the flow of types inferred.


 Doesn't "Dim" (without an "As" clause) declare a variant rather than a
 compile-time-inferred static type? Or did that change in VB.NET?


What MS did was basically just drop Visual Basic, lot's of rusty coders 

dying dynamic scripting language with a similar name. It is a different 
language altogether though, even D is more dynamic than VB.NET.
Jan 13 2010
parent "Nick Sabalausky" <a a.a> writes:
"Lutger" <lutger.blijdestijn gmail.com> wrote in message 
news:hilifj$7u7$1 digitalmars.com...

 On 01/13/2010 10:22 PM, Nick Sabalausky wrote:

 "Lutger"<lutger.blijdestijn gmail.com>  wrote in message
 news:hil6gr$2hmn$1 digitalmars.com...

 All ML derived languages do this much more extensively and they even 
 don't

 the
 same thing. The nice thing with those languages is that if you code in
 Visual Studio, you only have to hover above the variabele and the type
 pops up. Most IDE's have this btw, including descent, so that takes away
 the concern of having to remember the flow of types inferred.


 Doesn't "Dim" (without an "As" clause) declare a variant rather than a
 compile-time-inferred static type? Or did that change in VB.NET?


 What MS did was basically just drop Visual Basic, lot's of rusty coders 
 lost their job because of it.


Well, from what I've seen from various co-workers, anyone who could only do 
VB wasn't much of a programmer to begin with.



 with a similar name.
 It is a different language altogether though


Oh yea, I knew that, I just didn't realize that "Dim" without "As" has 
become an "auto"-like thing.
Jan 13 2010
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Justin Johansson" <no spam.com> wrote in message 
news:hiktil$20ai$1 digitalmars.com...

 Happy New Year 2010 Everybody.

 Having resumed C++ nationality for the last few months, I kind of miss D's 
 auto keyword.

 I am wondering, though, from an OO/polymorphism perspective, and UML and 
 sound software engineering perspective as well, what does D's auto keyword 
 buy you except (perhaps) laziness (in keystrokes)?


It makes it possible to have one variable's type match that of another 
variable without having to update as many places when you want to change. 
Ex:

---------------
class Foo {
    wchar x;
    void bar() {
        wchar[] y = x ~ "stuff";
        wchar[] z = y ~ x;
    }
}
---------------

Now if I decide I want 'x' to be a 'char', I have to remember to change 
'wchar'->'char' in all three declarations. But if 'y' and 'z' are declared 
with auto, all I have to do is change the declaration of 'x'. You could also 
get the same effect with typeof(), but that's more verbose and less DRY.
Jan 13 2010
prev sibling parent reply downs <default_357-line yahoo.de> writes:
Justin Johansson wrote:

 Happy New Year 2010 Everybody.
 
 Having resumed C++ nationality for the last few months, I kind of miss D's
auto keyword.
 


If you're on gcc or a compiler that allows the typeof extension:

#define DECL(A, B) typeof(B) A = B

:)
Jan 18 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"downs" <default_357-line yahoo.de> wrote in message 
news:hj1m0r$1k3l$1 digitalmars.com...

 Justin Johansson wrote:

 Happy New Year 2010 Everybody.

 Having resumed C++ nationality for the last few months, I kind of miss 
 D's auto keyword.


 If you're on gcc or a compiler that allows the typeof extension:

 #define DECL(A, B) typeof(B) A = B

 :)


Heh, I've done something similar in generic D code :)
Jan 18 2010
prev sibling parent Justin Johansson <no spam.com> writes:
downs wrote:

 Justin Johansson wrote:

 Happy New Year 2010 Everybody.

 Having resumed C++ nationality for the last few months, I kind of miss D's
auto keyword.


 
 If you're on gcc or a compiler that allows the typeof extension:
 
 #define DECL(A, B) typeof(B) A = B
 
 :)


Thanks. I uncovered the keyword recently when I inadvertently typed 
"typeof" instead of "typeid" and the editor in Eclipse CDT made no 
complaint.  Consequently I searched both web and boost source for
for usages of typeof and soon found that it was just an extension
for gcc (and perhaps some others).

It's a real pity for C++ that typeof keyword hasn't been standardized. 
Accordingly Boost doesn't use typeof.  However, I noticed that they 
sometimes make some use of the 
"typedef-decl-nested-inside-a-class-or-struct-trick" to exact static
type on occasions when typeof would otherwise suffice.

Cheers
Justin Johansson
Jan 26 2010