www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What is the correct use of auto?

reply "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
I have been reading through the specification and playing with D more 
and more, what is the purpose of auto. I can understand in languages 
with scalar types handling datatypes on assignment but on a strictly 
typed language like C or D when would auto(as a variable declaration) 
provide more useful functionality then it removes from readability.

When would this be useful rather then simply specifying the type?
Apr 10 2008
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
A great example is when using a library.  Instead of using a "void*" or 
something like that, you'd use an auto.

Example:

auto valueType = library.getSomething();

auto souffle = library.makeSomethingSouffle(valueType);
library.somethingElse(souffle);

Another use is when a particular section of your code doesn't care about 
the type, and you're just paper-pushing.  This way, even if you need to 
change the type later, you don't have to revisit the code (just 
recompile it.)

It's also handy for this:

auto abc = new com.example.somethinglong.modulename.Package();

Although mostly you would use an alias for that anyway.

And that's not even mentioning templates, where it's very very useful.

-[Unknown]


Hans W. Uhlig wrote:

 I have been reading through the specification and playing with D more 
 and more, what is the purpose of auto. I can understand in languages 
 with scalar types handling datatypes on assignment but on a strictly 
 typed language like C or D when would auto(as a variable declaration) 
 provide more useful functionality then it removes from readability.
 
 When would this be useful rather then simply specifying the type?
Apr 10 2008
parent reply "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
Unknown W. Brackets wrote:

 A great example is when using a library.  Instead of using a "void*" or 
 something like that, you'd use an auto.
 
 Example:
 
 auto valueType = library.getSomething();


I am coming from C and Java (sorry no C++), why wouldn't you declare a 
typed variable to store the class. Doesn't using auto introduce 
ambiguity to the compiler and the code itself.

And this is secondary but how would you use any form of autosense 
against this since its type can change from execution to execution.


 
 auto souffle = library.makeSomethingSouffle(valueType);
 library.somethingElse(souffle);
 


Again what is a souffle and why wouldnt you want it to be
Souffle mySouffle = library.makeSomethingSouffle(valueType); so that its 
properties are known at compile time.


 Another use is when a particular section of your code doesn't care about 
 the type, and you're just paper-pushing.  This way, even if you need to 
 change the type later, you don't have to revisit the code (just 
 recompile it.)


why bother to paper push if the value is unnecessary. Why not simply 
discard and move on?


 
 It's also handy for this:
 
 auto abc = new com.example.somethinglong.modulename.Package();
 
 Although mostly you would use an alias for that anyway.
 
 And that's not even mentioning templates, where it's very very useful.
 
 -[Unknown]
 
 
 Hans W. Uhlig wrote:

 I have been reading through the specification and playing with D more 
 and more, what is the purpose of auto. I can understand in languages 
 with scalar types handling datatypes on assignment but on a strictly 
 typed language like C or D when would auto(as a variable declaration) 
 provide more useful functionality then it removes from readability.

 When would this be useful rather then simply specifying the type?
Apr 11 2008
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Understand that "auto" cannot be used as a return type.  Thus, 
"library.getSomething()" has a concrete, deduceable type.

In other words, for:

auto valueType = library.getSomething();

Always has a single type for "auto".  The type is determined during 
compilation, *not* during runtime.

So, suppose this is some struct.  In C, you often use structs to pass 
around state.  I'm just suggesting that when you don't know/care what 
the variable is, you let the compiler deal with it (instead of the 
human, bad you.)

Autosense (I assume you're talking about IDEs) can be determined because 
of the return type of library.getSomething().  It is completely 
deterministic.

The "souffle" variables properties are entirely known at compile time. 
They simply are not being specified by you (most likely because you 
neither know its properties nor care.)  The compiler knows all.

It's important to understand that after compiling, "auto" and "Souffle" 
are exactly equivalent there.  The compiler determines that it is 
"Souffle" and it is as if you had typed that (you just didn't.)

Paper pushing: often you are shuffling around a value between different 
functions.  It could be an int handle, a void pointer, a struct, a 
pointer to something, a class object, a string.  Who cares?  Do you 
care?  No.  As long as the compiler knows what it is, that's all you 
care about.

Function 1 will always return a value that function 2 will take, and you 
never know its properties anyway.  So you're pushing a value between the 
two and you don't care about its actual type or value.  Let the compiler 
worry about that.

-[Unknown]


Hans W. Uhlig wrote:

 Unknown W. Brackets wrote:

 A great example is when using a library.  Instead of using a "void*" 
 or something like that, you'd use an auto.

 Example:

 auto valueType = library.getSomething();


 
 I am coming from C and Java (sorry no C++), why wouldn't you declare a 
 typed variable to store the class. Doesn't using auto introduce 
 ambiguity to the compiler and the code itself.
 
 And this is secondary but how would you use any form of autosense 
 against this since its type can change from execution to execution.
 

 auto souffle = library.makeSomethingSouffle(valueType);
 library.somethingElse(souffle);


 
 Again what is a souffle and why wouldnt you want it to be
 Souffle mySouffle = library.makeSomethingSouffle(valueType); so that its 
 properties are known at compile time.
 

 Another use is when a particular section of your code doesn't care 
 about the type, and you're just paper-pushing.  This way, even if you 
 need to change the type later, you don't have to revisit the code 
 (just recompile it.)


 
 why bother to paper push if the value is unnecessary. Why not simply 
 discard and move on?
 

 It's also handy for this:

 auto abc = new com.example.somethinglong.modulename.Package();

 Although mostly you would use an alias for that anyway.

 And that's not even mentioning templates, where it's very very useful.

 -[Unknown]


 Hans W. Uhlig wrote:

 I have been reading through the specification and playing with D more 
 and more, what is the purpose of auto. I can understand in languages 
 with scalar types handling datatypes on assignment but on a strictly 
 typed language like C or D when would auto(as a variable declaration) 
 provide more useful functionality then it removes from readability.

 When would this be useful rather then simply specifying the type?
Apr 11 2008
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
It might help you to understand auto if you try this:

auto i;

It will not compile.  In this case, i has no type.  Remember that i is 
not some boxed variable or something... it's simply type inference.

-[Unknown]


Hans W. Uhlig wrote:

 Unknown W. Brackets wrote:

 A great example is when using a library.  Instead of using a "void*" 
 or something like that, you'd use an auto.

 Example:

 auto valueType = library.getSomething();


 
 I am coming from C and Java (sorry no C++), why wouldn't you declare a 
 typed variable to store the class. Doesn't using auto introduce 
 ambiguity to the compiler and the code itself.
 
 And this is secondary but how would you use any form of autosense 
 against this since its type can change from execution to execution.
 

 auto souffle = library.makeSomethingSouffle(valueType);
 library.somethingElse(souffle);


 
 Again what is a souffle and why wouldnt you want it to be
 Souffle mySouffle = library.makeSomethingSouffle(valueType); so that its 
 properties are known at compile time.
 

 Another use is when a particular section of your code doesn't care 
 about the type, and you're just paper-pushing.  This way, even if you 
 need to change the type later, you don't have to revisit the code 
 (just recompile it.)


 
 why bother to paper push if the value is unnecessary. Why not simply 
 discard and move on?
 

 It's also handy for this:

 auto abc = new com.example.somethinglong.modulename.Package();

 Although mostly you would use an alias for that anyway.

 And that's not even mentioning templates, where it's very very useful.

 -[Unknown]


 Hans W. Uhlig wrote:

 I have been reading through the specification and playing with D more 
 and more, what is the purpose of auto. I can understand in languages 
 with scalar types handling datatypes on assignment but on a strictly 
 typed language like C or D when would auto(as a variable declaration) 
 provide more useful functionality then it removes from readability.

 When would this be useful rather then simply specifying the type?
Apr 11 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Unknown W. Brackets wrote:

 It might help you to understand auto if you try this:
 
 auto i;
 
 It will not compile.  In this case, i has no type.  Remember that i is 
 not some boxed variable or something... it's simply type inference.
 
 -[Unknown]


And also you should be aware that it's the *lack* of a specific type 
that triggers the inference, not the *presence* of auto.  These do type 
inference too:

// D1
static x = 2.3;
static assert(is(typeof(x)==double));

const y = "hello";
static assert(is(typeof(y)==char[]));

--bb
Apr 11 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Bill Baxter wrote:

 Unknown W. Brackets wrote:

 It might help you to understand auto if you try this:

 auto i;

 It will not compile.  In this case, i has no type.  Remember that i is 
 not some boxed variable or something... it's simply type inference.

 -[Unknown]


 
 And also you should be aware that it's the *lack* of a specific type 
 that triggers the inference, not the *presence* of auto.  These do type 
 inference too:
 
 // D1
 static x = 2.3;
 static assert(is(typeof(x)==double));
 
 const y = "hello";
 static assert(is(typeof(y)==char[]));
 
 --bb


In fact, if you say "auto static x = new object()" the "auto" has a 
different meaning (the same meaning as "scope"). This part, of course, 
is inane and confusing but good for backwards compatibility.
Apr 11 2008
parent reply Georg Wrede <georg nospam.org> writes:
Robert Fraser wrote:

 In fact, if you say "auto static x = new object()" the "auto" has a 
 different meaning (the same meaning as "scope"). This part, of course, 
 is inane and confusing but good for backwards compatibility.


We oughtta do Spring Cleaning in D.

If we don't watch it, soon D will become cluttered with ever so subtle 
crap like this, that only serves as hindrance to those who try to learn 
the language. There are many other examples of similar small things, 
that we hardly notice, but that really make a difference in how easy and 
fast folks can get up to confidence with the language.

And, yes, I know, whenever somebody takes them up, the answer is always 
like, it's for backward compatibility, for the ease of C(++) guys, and 
whatever.

It's like a single man's dwellings. A little dust here and there, and 
underware on the armchair.

OTOH, to give Walter credit, D doesn't look anything like Perl. Bet 
Larry has beercans in the bed.
Apr 11 2008
parent "Hans W. Uhlig" <huhlig gmail.com> writes:
Georg Wrede wrote:

 Robert Fraser wrote:

 In fact, if you say "auto static x = new object()" the "auto" has a 
 different meaning (the same meaning as "scope"). This part, of course, 
 is inane and confusing but good for backwards compatibility.


 
 We oughtta do Spring Cleaning in D.
 
 If we don't watch it, soon D will become cluttered with ever so subtle 
 crap like this, that only serves as hindrance to those who try to learn 
 the language. There are many other examples of similar small things, 
 that we hardly notice, but that really make a difference in how easy and 
 fast folks can get up to confidence with the language.
 
 And, yes, I know, whenever somebody takes them up, the answer is always 
 like, it's for backward compatibility, for the ease of C(++) guys, and 
 whatever.
 
 It's like a single man's dwellings. A little dust here and there, and 
 underware on the armchair.
 
 OTOH, to give Walter credit, D doesn't look anything like Perl. Bet 
 Larry has beercans in the bed.


I think I have to agree, D1 and D2 shouldnt need to be backwards 
compatible. Bad ideas or outdated ones I can fully agree need to be 
striped out
Apr 18 2008
prev sibling next sibling parent reply Sean Reque <seanthenewt yahoo.com> writes:
Hans W. Uhlig Wrote:


 I have been reading through the specification and playing with D more 
 and more, what is the purpose of auto. I can understand in languages 
 with scalar types handling datatypes on assignment but on a strictly 
 typed language like C or D when would auto(as a variable declaration) 
 provide more useful functionality then it removes from readability.
 
 When would this be useful rather then simply specifying the type?


auto is also a very handy syntactic sugar when the type of the object you are
declaring is very long. In such cases, its often easier to read the auto
keyword and infer what the object is by its name and how it is used, rather
than by reading its type. For instance, instead of writing out a function
pointer or delegate with a long signature, you could declare it as auto and
save yourself and future code readers some time if you both understand that
what you have is a delegate.
Apr 11 2008
parent "Scott S. McCoy" <tag cpan.org> writes:
On Fri, 2008-04-11 at 03:01 -0400, Sean Reque wrote:

 auto is also a very handy syntactic sugar when the type of the object
 you are declaring is very long.


Like:

NonblockingThreadsafeQueue!(QueueItem!(TimedEventPriorty,bool
delegate())) foo = object.getQueue();

... it looks a lot nicer as...

auto foo = object.getQueue(); /* Especially since it has to be obvious
to the compiler what you're asking for, so it must be defined someplace
*/
Apr 13 2008
prev sibling next sibling parent Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Hans W. Uhlig wrote:

 I have been reading through the specification and playing with D more 
 and more, what is the purpose of auto. I can understand in languages 
 with scalar types handling datatypes on assignment but on a strictly 
 typed language like C or D when would auto(as a variable declaration) 
 provide more useful functionality then it removes from readability.
 
 When would this be useful rather then simply specifying the type?


Templates, where the specific type(s) are not known to the template 
writer !

It is the same reason why the next version of C++ will have this 
functionality also.
Apr 11 2008
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Hans W. Uhlig" <huhlig clickconsulting.com> wrote in message 
news:ftmkv2$2gj$1 digitalmars.com...


 When would this be useful rather then simply specifying the type?


This was my feeling at first too.  Then I started using it.  ;)
Apr 11 2008
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Hans W. Uhlig" wrote

I have been reading through the specification and playing with D more and 
more, what is the purpose of auto. I can understand in languages with 
scalar types handling datatypes on assignment but on a strictly typed 
language like C or D when would auto(as a variable declaration) provide 
more useful functionality then it removes from readability.

 When would this be useful rather then simply specifying the type?


The best reason for auto is maintainability.

If you decide to change what some function returns, then you have to go 
through all your code and change the return type in all places it is used. 
If you use auto, it's already done :)  Most frequent thing that happens to 
me is, I find I've declared something as returning int, and realize it 
really should have been uint.

The second best reason is for template instantiation:

TemplateClass!(int, string, 5) variable = new TemplateClass!(int, string, 
5);
vs.
auto variable = new TemplateClass!(int, string, 5);
There's also a maintainability aspect to that as well, if you decide to 
change the template type.

I've spottily used auto, and I've found in many cases that I wished I had 
used it everywhere :)  seldom does it hurt you to use it, and it's usually 
pretty clear what it means.

-Steve
Apr 11 2008
parent Tower Ty <tytower hotmail.com.au> writes:
Steven Schveighoffer Wrote:


 "Hans W. Uhlig" wrote

I have been reading through the specification and playing with D more and 
more, what is the purpose of auto. I can understand in languages with 
scalar types handling datatypes on assignment but on a strictly typed 
language like C or D when would auto(as a variable declaration) provide 
more useful functionality then it removes from readability.

 When would this be useful rather then simply specifying the type?


 
 The best reason for auto is maintainability.
 
 If you decide to change what some function returns, then you have to go 
 through all your code and change the return type in all places it is used. 
 If you use auto, it's already done :)  Most frequent thing that happens to 
 me is, I find I've declared something as returning int, and realize it 
 really should have been uint.
 
 The second best reason is for template instantiation:
 
 TemplateClass!(int, string, 5) variable = new TemplateClass!(int, string, 
 5);
 vs.
 auto variable = new TemplateClass!(int, string, 5);
 There's also a maintainability aspect to that as well, if you decide to 
 change the template type.
 
 I've spottily used auto, and I've found in many cases that I wished I had 
 used it everywhere :)  seldom does it hurt you to use it, and it's usually 
 pretty clear what it means.
 
 -Steve 
 
 


Steven Schveighoffer Wrote:



 If you decide to change what some function returns, then you have to go 
 through all your code and change the return type in all places it is used. 
 If you use auto, it's already done :)  Most frequent thing that happens to 
 me is, I find I've declared something as returning int, and realize it 
 really should have been uint.
 
 The second best reason is for template instantiation:
 
 TemplateClass!(int, string, 5) variable = new TemplateClass!(int, string, 
 5);
 vs.
 auto variable = new TemplateClass!(int, string, 5);
 There's also a maintainability aspect to that as well, if you decide to 
 change the template type.
 
 I've spottily used auto, and I've found in many cases that I wished I had 
 used it everywhere :)  seldom does it hurt you to use it, and it's usually 
 pretty clear what it means.
 
 -Steve 


Ive just read through all the souffle , and somethingelse  and beercans and
underwear type answers here which are just pure time wasting crap. 

The above is the first answer that is informative , readable and understandable
-Thanks Steve
Apr 12 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Hans W. Uhlig wrote:

 I have been reading through the specification and playing with D more 
 and more, what is the purpose of auto. I can understand in languages 
 with scalar types handling datatypes on assignment but on a strictly 
 typed language like C or D when would auto(as a variable declaration) 
 provide more useful functionality then it removes from readability.
 
 When would this be useful rather then simply specifying the type?


I want to (someday, not any time soon) add a feature to Descent whereby 
"auto" can be converted to the actual type automatically throughout a 
source file. That way, you can get the advantages of less typing (as in 
"Punch the keys for God's sake", not "int vs. long") while still getting 
the readability after the refactoring.
Apr 11 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Robert Fraser escribió:

 Hans W. Uhlig wrote:

 I have been reading through the specification and playing with D more 
 and more, what is the purpose of auto. I can understand in languages 
 with scalar types handling datatypes on assignment but on a strictly 
 typed language like C or D when would auto(as a variable declaration) 
 provide more useful functionality then it removes from readability.

 When would this be useful rather then simply specifying the type?


 
 I want to (someday, not any time soon) add a feature to Descent whereby 
 "auto" can be converted to the actual type automatically throughout a 
 source file. That way, you can get the advantages of less typing (as in 
 "Punch the keys for God's sake", not "int vs. long") while still getting 
 the readability after the refactoring.


I thought that too. :-)

It can be done very easily, since bindings already have this 
information, but AST rewriting must be finished (but for this, only the 
code that rewrites a variable declaration).
Apr 11 2008
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Ary Borenszweig escribió:

 Robert Fraser escribió:

 Hans W. Uhlig wrote:

 I have been reading through the specification and playing with D more 
 and more, what is the purpose of auto. I can understand in languages 
 with scalar types handling datatypes on assignment but on a strictly 
 typed language like C or D when would auto(as a variable declaration) 
 provide more useful functionality then it removes from readability.

 When would this be useful rather then simply specifying the type?


 I want to (someday, not any time soon) add a feature to Descent 
 whereby "auto" can be converted to the actual type automatically 
 throughout a source file. That way, you can get the advantages of less 
 typing (as in "Punch the keys for God's sake", not "int vs. long") 
 while still getting the readability after the refactoring.


 
 I thought that too. :-)
 
 It can be done very easily, since bindings already have this 
 information, but AST rewriting must be finished (but for this, only the 
 code that rewrites a variable declaration).


In fact, if you hover over an auto variable, Descent will tell you it's 
type. And, of course, autocompletion works as expected. (yes, with all 
the bugs, but I'm hoping to release soon something that works flawlessly).

This answers the question "When would this be useful rather then simply 
specifying the type?": when you are lazy to type the type, or you just 
don't care.
Apr 11 2008
prev sibling next sibling parent reply Georg Wrede <georg nospam.org> writes:
Robert Fraser wrote:

 Hans W. Uhlig wrote:
 

 I have been reading through the specification and playing with D more 
 and more, what is the purpose of auto. I can understand in languages 
 with scalar types handling datatypes on assignment but on a strictly 
 typed language like C or D when would auto(as a variable declaration) 
 provide more useful functionality then it removes from readability.

 When would this be useful rather then simply specifying the type?


 
 I want to (someday, not any time soon) add a feature to Descent whereby 
 "auto" can be converted to the actual type automatically throughout a 
 source file. That way, you can get the advantages of less typing (as in 
 "Punch the keys for God's sake", not "int vs. long") while still getting 
 the readability after the refactoring.


I wouldn't use that feature.

I admit, in the beginning, I was against auto, but today, I think it's 
an excellent thing. And not because it could (in some situations) save 
typing.
Apr 11 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Georg Wrede wrote:

 Robert Fraser wrote:

 Hans W. Uhlig wrote:


 I have been reading through the specification and playing with D more 
 and more, what is the purpose of auto. I can understand in languages 
 with scalar types handling datatypes on assignment but on a strictly 
 typed language like C or D when would auto(as a variable declaration) 
 provide more useful functionality then it removes from readability.

 When would this be useful rather then simply specifying the type?


 I want to (someday, not any time soon) add a feature to Descent 
 whereby "auto" can be converted to the actual type automatically 
 throughout a source file. That way, you can get the advantages of less 
 typing (as in "Punch the keys for God's sake", not "int vs. long") 
 while still getting the readability after the refactoring.


 
 I wouldn't use that feature.
 
 I admit, in the beginning, I was against auto, but today, I think it's 
 an excellent thing. And not because it could (in some situations) save 
 typing.


FWIW, neither would I (since it kills the portability/maintainability 
aspect of auto). But it would be nice to have for people who do want it.

Actually, I would run it on all the Tango examples, since "auto" has no 
place in examples -- If I'm learning how to use an API, I want to know 
the actual types of the stuff I'm getting without looking up every function.
Apr 12 2008
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I completely disagree.  Especially when your dogfood is good, you should 
share it and not horde it for yourself.

Teaching newbies to program differently than you think is best seems 
wrong to me.

-[Unknown]


Robert Fraser wrote:

 Actually, I would run it on all the Tango examples, since "auto" has no 
 place in examples -- If I'm learning how to use an API, I want to know 
 the actual types of the stuff I'm getting without looking up every 
 function.
Apr 12 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Unknown W. Brackets wrote:

 I completely disagree.  Especially when your dogfood is good, you should 
 share it and not horde it for yourself.
 
 Teaching newbies to program differently than you think is best seems 
 wrong to me.
 
 -[Unknown]


I was thinking of "newbies to the library" instead of "newbies to the 
language". It's good practice in the language, but I remember trying to 
use a Mango servlet and spending an hour looking up what types were 
returned by functions in examples so I could figure out how to extend & 
change the example code.
Apr 12 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Robert,


 Unknown W. Brackets wrote:
 

 I completely disagree.  Especially when your dogfood is good, you
 should share it and not horde it for yourself.
 
 Teaching newbies to program differently than you think is best seems
 wrong to me.
 
 -[Unknown]
 


 I was thinking of "newbies to the library" instead of "newbies to the
 language". It's good practice in the language, but I remember trying
 to use a Mango servlet and spending an hour looking up what types were
 returned by functions in examples so I could figure out how to extend
 & change the example code.
 


quick, ugly (and slightly profain).

template WT_TypeIsThis(T)
{
   pragma(msg,T.stringof)
}

use like this:

WT_TypeIsThis! (typeof(someFnc());  // man I like D's template Syntax!!!!!!!
Apr 12 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
BCS wrote:

 Reply to Robert,
 

 Unknown W. Brackets wrote:


 I completely disagree.  Especially when your dogfood is good, you
 should share it and not horde it for yourself.

 Teaching newbies to program differently than you think is best seems
 wrong to me.

 -[Unknown]


 I was thinking of "newbies to the library" instead of "newbies to the
 language". It's good practice in the language, but I remember trying
 to use a Mango servlet and spending an hour looking up what types were
 returned by functions in examples so I could figure out how to extend
 & change the example code.


 
 quick, ugly (and slightly profain).
 
 template WT_TypeIsThis(T)
 {
   pragma(msg,T.stringof)
 }
 
 use like this:
 
 WT_TypeIsThis! (typeof(someFnc());  // man I like D's template 
 Syntax!!!!!!!


Indeed that works. These days, I'd just load it up in Descent & hover 
over it to find out :-). But back when I was first learning D, I didn't 
know the template method and IDEs weren't mature enough for that yet.
Apr 12 2008
prev sibling parent Georg Wrede <georg nospam.org> writes:
Robert Fraser wrote:

 Unknown W. Brackets wrote:
 

 I completely disagree.  Especially when your dogfood is good, you 
 should share it and not horde it for yourself.

 Teaching newbies to program differently than you think is best seems 
 wrong to me.


 
 I was thinking of "newbies to the library" instead of "newbies to the 
 language". It's good practice in the language, but I remember trying to 
 use a Mango servlet and spending an hour looking up what types were 
 returned by functions in examples so I could figure out how to extend & 
 change the example code.


If a writer is /both/ talented and diligent, he writes every single 
sentence separately. At /each/ single sentence he addresses 4 separate 
audiences, and treads so carefully that /each/ of these 4 audiences 
actually gets something out of the sentence, while none of the others 
feel insulted.

Good examples are Knuth's books, K&R, The Java Programming Language (by 
Arnold & Gosling), Turbo Pascal Reference Manual, for version 3.0 (no 
authors, just Borland).

The 4 audiences are: total newbies (not belittling their intelligence), 
newbies to the particular language (but accomplished, or possibly even 
Veteran Programmers elsewhere), those who have begun with this 
particular language, but who haven't had any Formal Education in 
Programming, and finally, those who are both seasoned programmers and 
who also have extensive experience in the programming language at hand.
Apr 13 2008
prev sibling parent reply Georg Wrede <georg nospam.org> writes:
Unknown W. Brackets wrote:

 Robert Fraser wrote:

 Actually, I would run it on all the Tango examples, since "auto"
 has no place in examples -- If I'm learning how to use an API, I
 want to know the actual types of the stuff I'm getting without
 looking up every function.





 I completely disagree.  Especially when your dogfood is good, you
 should share it and not horde it for yourself.
 
 Teaching newbies to program differently than you think is best seems 
 wrong to me.


The last phrase I entirely agree with. Replacing earlier "when your 
dogfood is good" with "when your dogfood is good for you".

Now, what is different here is, there's another thing at issue here than 
how newbies/old hands should program. In other words, pedagogically, 
this is an exception case.

Why? Well, here the point is not whether to encourage or discourage the 
use of "auto". The point is (in the examples which we're talking about, 
anyway), all of those examples TALK ABOUT SOMETHING ELSE than if you 
should use auto or not. So, to make the issue clear, one should have 
"unabridged" D code visible.

I'm both sorry, and angry, over that I simply don't seem to express this 
more precisely, nor more convincingly -- sorry and angry with myself.

Those of you who have kids, must have been in the situation where you've 
"known better, but can't say _why_ to your kids in such language and 
terms that they'd get convinced". I'm there now, with this issue.

To sum it up, "auto" should /never/ appear in any example code (either 
here nor in DDJ), all examples that are not /directly/ associated with 
"auto" should simply not contain it. BUT, on the First Page of Proper 
Conduct in D, "auto" should be prominently displayed as the Proper Way.
Apr 13 2008
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
I might suggest using analogies that describe the people you're talking 
to as your children aren't always going to help you.  you have used a 
lot lately.

Anyway, I don't mind that.  Unfortunately, the problem here is your 
analogy implies you're not interested in hearing arguments against your 
position, which is unfortunate and hopefully untrue.

It is my belief that many people (at least this is true for me) learn 
programming and new languages from examples and reference code.  Not 
using auto in examples just means I'm more likely to be confused when I 
*do* see it (most likely with zero documentation or comments) outside of 
an example.  In addition, if I write code it's unlikely I'll use it, 
*even though* it would make more code better, easier to read and type, 
and more maintainable.

If you think that "auto" is a bad feature, I understand that.  But using 
it yourself, and omitting it from all documentation, is not helpful to 
people trying to learn so much as you say.

-[Unknown]


Georg Wrede wrote:

 Unknown W. Brackets wrote:

 Robert Fraser wrote:

 Actually, I would run it on all the Tango examples, since "auto"
 has no place in examples -- If I'm learning how to use an API, I
 want to know the actual types of the stuff I'm getting without
 looking up every function.




 

 I completely disagree.  Especially when your dogfood is good, you
 should share it and not horde it for yourself.

 Teaching newbies to program differently than you think is best seems 
 wrong to me.


 
 The last phrase I entirely agree with. Replacing earlier "when your 
 dogfood is good" with "when your dogfood is good for you".
 
 Now, what is different here is, there's another thing at issue here than 
 how newbies/old hands should program. In other words, pedagogically, 
 this is an exception case.
 
 Why? Well, here the point is not whether to encourage or discourage the 
 use of "auto". The point is (in the examples which we're talking about, 
 anyway), all of those examples TALK ABOUT SOMETHING ELSE than if you 
 should use auto or not. So, to make the issue clear, one should have 
 "unabridged" D code visible.
 
 I'm both sorry, and angry, over that I simply don't seem to express this 
 more precisely, nor more convincingly -- sorry and angry with myself.
 
 Those of you who have kids, must have been in the situation where you've 
 "known better, but can't say _why_ to your kids in such language and 
 terms that they'd get convinced". I'm there now, with this issue.
 
 To sum it up, "auto" should /never/ appear in any example code (either 
 here nor in DDJ), all examples that are not /directly/ associated with 
 "auto" should simply not contain it. BUT, on the First Page of Proper 
 Conduct in D, "auto" should be prominently displayed as the Proper Way.
Apr 13 2008
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Georg Wrede wrote:

 To sum it up, "auto" should /never/ appear in any example code (either 
 here nor in DDJ), all examples that are not /directly/ associated with 
 "auto" should simply not contain it.


I wouldn't agree with that. It's just that the use of auto shouldn't 
hide anything from the user. If you say

auto list = new ArraySeq!(GodzillaAttackLocationDefenseStrategy)();

its type is quite clear.
Apr 13 2008
prev sibling parent reply Georg Wrede <georg nospam.org> writes:
Robert Fraser wrote:

 Georg Wrede wrote:

 Robert Fraser wrote:

 Hans W. Uhlig wrote:


 I have been reading through the specification and playing with D 
 more and more, what is the purpose of auto. I can understand in 
 languages with scalar types handling datatypes on assignment but on 
 a strictly typed language like C or D when would auto(as a variable 
 declaration) provide more useful functionality then it removes from 
 readability.

 When would this be useful rather then simply specifying the type?


 I want to (someday, not any time soon) add a feature to Descent 
 whereby "auto" can be converted to the actual type automatically 
 throughout a source file. That way, you can get the advantages of 
 less typing (as in "Punch the keys for God's sake", not "int vs. 
 long") while still getting the readability after the refactoring.


 I wouldn't use that feature.

 I admit, in the beginning, I was against auto, but today, I think it's 
 an excellent thing. And not because it could (in some situations) save 
 typing.


 
 FWIW, neither would I (since it kills the portability/maintainability 
 aspect of auto). But it would be nice to have for people who do want it.
 
 Actually, I would run it on all the Tango examples, since "auto" has no 
 place in examples -- If I'm learning how to use an API, I want to know 
 the actual types of the stuff I'm getting without looking up every 
 function.


THIS is something I've posted reams about, ever since auto became part of D!

While auto might (and probably is) an everyday part of Good D Code, it 
STILL has no place in examples.

(( An example: My 8 and 10 years old sons walked with me today. Neither 
looked left nor right when we crossed the street. I told them (for the 
200th time) that, "hey, Daddy gets distracted with you guys fooling 
around, and if Daddy misses a coming car, then we all die". Next 
crossing, and I was the only one who even tried to look around.

OK, safety (like in buckling up (non-US: wearing safety belts in a 
car)), has nothing to do with this comment. The only point here is, that 
for people who don't *personally* "see" the point, no amount of nagging 
seems to drive the issue through. And "auto" with D examples, seems to 
be the same. Unfortunately. ))

So, please, never again a D code example with auto. Thank you all!!!
Apr 13 2008
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Why?  I'm not sure I see the relevance of your analogies to the point.

Surely no one shall die if they use auto.  Also, not knowing what 
something is (which can cause you no harm directly) is very different 
from not knowing where incoming danger might be.

I think you're trying to say that having autos in examples is like 
having mines, in that they are possible points of confusion to newcomers 
(who will not know what those things are.)  You may also be trying to 
say that using auto in examples teaches people to use auto more than 
they should.

However, I would say that auto should not be used, except in any case 
where the type auto is representing:

	- is unimportant to surrounding code (it is being paper-pushed.)
	- is unlikely to be used in any way other than the represented way 
(e.g. has no other useful methods than are already being called.)
	- is documented in some comment in the example.
	- is an example type, with no actual importance to the example (e.g. to 
be passed to a method that takes any value, which is what the example is 
showing.)

Here is an example which uses auto.  It is very simple and clear, and 
auto is making the example better.

// How to write to stderr
import std.stdio;

int main()
{
	// Most anything can be written using writefln().
	// If it's an object, it needs a toString() method.
	auto data = 42;

	// This outputs data (as a string) to stderr, and then a newline.
	writefln(stderr, "Look at this: %s", data);

	// You can also use writeln() for unformatted data.
	writefln(stderr, data);
}

Also, anytime you have:

auto something = new Something();

It's reasonable to assume the reader of the example will understand what 
something is, imho.  This is especially true with template examples, 
where someone may (additionally) be overwhelmed by the extraneous 
information in the declaration.

-[Unknown]


Georg Wrede wrote:

 THIS is something I've posted reams about, ever since auto became part 
 of D!
 
 While auto might (and probably is) an everyday part of Good D Code, it 
 STILL has no place in examples.
 
 (( An example: My 8 and 10 years old sons walked with me today. Neither 
 looked left nor right when we crossed the street. I told them (for the 
 200th time) that, "hey, Daddy gets distracted with you guys fooling 
 around, and if Daddy misses a coming car, then we all die". Next 
 crossing, and I was the only one who even tried to look around.
 
 OK, safety (like in buckling up (non-US: wearing safety belts in a 
 car)), has nothing to do with this comment. The only point here is, that 
 for people who don't *personally* "see" the point, no amount of nagging 
 seems to drive the issue through. And "auto" with D examples, seems to 
 be the same. Unfortunately. ))
 
 So, please, never again a D code example with auto. Thank you all!!!
Apr 13 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Unknown W. Brackets wrote:

 Why?  I'm not sure I see the relevance of your analogies to the point.
 
 Surely no one shall die if they use auto.  Also, not knowing what 
 something is (which can cause you no harm directly) is very different 
 from not knowing where incoming danger might be.
 
 I think you're trying to say that having autos in examples is like 
 having mines, in that they are possible points of confusion to newcomers 
 (who will not know what those things are.)  You may also be trying to 
 say that using auto in examples teaches people to use auto more than 
 they should.
 
 However, I would say that auto should not be used, except in any case 
 where the type auto is representing:
 
     - is unimportant to surrounding code (it is being paper-pushed.)


This is *NEVER* true in an example (unless the type being paper-pushed 
is from another API than the one being learned). Just because the 
example code never changes anything in the 
GodzillaAttackInitializationContext doesn't mean user code never will. 
If it's part of the API, its should be specified in the example.


     - is unlikely to be used in any way other than the represented way 
 (e.g. has no other useful methods than are already being called.)


Again, only if it's not part of the API being demonstrated.


     - is documented in some comment in the example.


I'd rather see the type in the code than in the comment, but this is OK, 
I guess.


     - is an example type, with no actual importance to the example (e.g. 
 to be passed to a method that takes any value, which is what the example 
 is showing.)


OK, I'll give you that, as long as it's documented. A better way might 
be to show the same function working with two different (specified) types.


 
 Here is an example which uses auto.  It is very simple and clear, and 
 auto is making the example better.
 
 // How to write to stderr
 import std.stdio;
 
 int main()
 {
     // Most anything can be written using writefln().
     // If it's an object, it needs a toString() method.
     auto data = 42;
 
     // This outputs data (as a string) to stderr, and then a newline.
     writefln(stderr, "Look at this: %s", data);
 
     // You can also use writeln() for unformatted data.
     writefln(stderr, data);
 }


That example would better have been shown by having an int and printing 
it, then having a string and printing it, and showing how writefln works 
for both. And I would argue that in that case, the types are paramount, 
since you're showing how writefln works with any type.


 Also, anytime you have:
 
 auto something = new Something();
 
 It's reasonable to assume the reader of the example will understand what 
 something is, imho.  This is especially true with template examples, 
 where someone may (additionally) be overwhelmed by the extraneous 
 information in the declaration.


OK, that's fine. But method returns aren't, since you have to look up 
the method.


 -[Unknown]


Here's an example of a BAD example from Mango that frustrated the **** 
out of me about a year ago:

     void testServletEngine (Logger log)
     {
         log.info ("registering servlets");

         // construct a servlet-provider
         auto sp = new ServletProvider;

         // create a context for example servlets
         auto example = sp.addContext (new ServletContext ("/example"));

         // create a context for admin servlets
         auto admin = sp.addContext (new AdminContext (sp, "/admin"));

         // map echo requests to our echo servlet
         sp.addMapping ("/echo", sp.addServlet (new Echo, "echo", example));

         // point the default context to the tango help files
         sp.addContext (new ServletContext ("", "../doc/html"));

         // map all other requests to our file servlet
         sp.addMapping ("/", sp.addServlet (new FileServlet, "files"));

         // fire up a server
         testServer (sp, log);
     }

The second and third autos are the big problem here. They say "create a 
context for example servlets" and "create a context for admin servlets", 
but nowhere in the example is it shown what a "context" is, and the type 
"context" refers to is a mango.net.ServletContext. You wouldn't know the 
exact type without looking up ServletProvider.addContext. The servlet 
context is definitely something users would want to change, so while 
it's just paper-pushing in this example it is not in real-world code.

Also, from later in the same file:

     auto output = response.buffer;

 From it's name, my initial reaction would be some sort of char[] or 
ubyte[]. Then suddenly, it's written to using the whisper syntax. In 
retrospect, it makes sense that it's a tango.io.model.IBuffer (a class I 
didn't even know existed, and have no idea what capabilities it has), 
but this is the stuff I had to look up, since it's not clear from its use.

I think there was a much more annoying one there, but I can't seem to 
find it right now.
Apr 13 2008
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Surely; but I think cases where you have to deal with another API (e.g. 
of another library) are actually very frequent.  Documenting them in 
your documentation may neither be prudent nor helpful.

Most of the time, using auto for a return type is bad.  However, it 
might be good - especially with a comment like this:

// Version 1 and 2 return different types here.
// Version 1 returns "Xyz" and version 2 returns "Abc".

Or also:

// The type returned here may change at some point.
// It will always have a "runFromGodzilla" method, which is the only one
// that is useful in this version of the library.

And similar.  Undocumented, or poorly documented, examples are another 
problem.  Telling me that your car runs badly without gas doesn't mean 
tell me anything about oil.  Sure, they may both be things to improve 
with your car.

I didn't say my example was perfect, but it isn't a wrong or confusing 
use of auto.  If I were really documenting the use of stderr, I'd 
probably show mainly strings, much more in the way of formatting, etc. 
Likely I would also describe why and how it is best for error messages, 
even possibly a basic primer on how to pipe it properly.

Sorry I did not give a fully developed example.  It was merely to 
illustrate, since I'm sure anyone participating in this conversation 
understands stderr.

I frankly hate Mango/Tango's abuse of the (), and etc.  I think it makes 
for hard to read code, confuses beginners, and isn't even clean.  I 
realize many disagree and this is obviously a personal opinion.

But I think anyone would agree that isn't a good example and auto has 
been misused there out of laziness.  I just think that saying "auto is 
wrong always" is very likely incorrect.

-[Unknown]


Robert Fraser wrote:

 Unknown W. Brackets wrote:

 Why?  I'm not sure I see the relevance of your analogies to the point.

 Surely no one shall die if they use auto.  Also, not knowing what 
 something is (which can cause you no harm directly) is very different 
 from not knowing where incoming danger might be.

 I think you're trying to say that having autos in examples is like 
 having mines, in that they are possible points of confusion to 
 newcomers (who will not know what those things are.)  You may also be 
 trying to say that using auto in examples teaches people to use auto 
 more than they should.

 However, I would say that auto should not be used, except in any case 
 where the type auto is representing:

     - is unimportant to surrounding code (it is being paper-pushed.)


 
 This is *NEVER* true in an example (unless the type being paper-pushed 
 is from another API than the one being learned). Just because the 
 example code never changes anything in the 
 GodzillaAttackInitializationContext doesn't mean user code never will. 
 If it's part of the API, its should be specified in the example.
 

     - is unlikely to be used in any way other than the represented way 
 (e.g. has no other useful methods than are already being called.)


 
 Again, only if it's not part of the API being demonstrated.
 

     - is documented in some comment in the example.


 
 I'd rather see the type in the code than in the comment, but this is OK, 
 I guess.
 

     - is an example type, with no actual importance to the example 
 (e.g. to be passed to a method that takes any value, which is what the 
 example is showing.)


 
 OK, I'll give you that, as long as it's documented. A better way might 
 be to show the same function working with two different (specified) types.
 

 Here is an example which uses auto.  It is very simple and clear, and 
 auto is making the example better.

 // How to write to stderr
 import std.stdio;

 int main()
 {
     // Most anything can be written using writefln().
     // If it's an object, it needs a toString() method.
     auto data = 42;

     // This outputs data (as a string) to stderr, and then a newline.
     writefln(stderr, "Look at this: %s", data);

     // You can also use writeln() for unformatted data.
     writefln(stderr, data);
 }


 
 That example would better have been shown by having an int and printing 
 it, then having a string and printing it, and showing how writefln works 
 for both. And I would argue that in that case, the types are paramount, 
 since you're showing how writefln works with any type.
 

 Also, anytime you have:

 auto something = new Something();

 It's reasonable to assume the reader of the example will understand 
 what something is, imho.  This is especially true with template 
 examples, where someone may (additionally) be overwhelmed by the 
 extraneous information in the declaration.


 
 OK, that's fine. But method returns aren't, since you have to look up 
 the method.
 

 -[Unknown]


 
 Here's an example of a BAD example from Mango that frustrated the **** 
 out of me about a year ago:
 
     void testServletEngine (Logger log)
     {
         log.info ("registering servlets");
 
         // construct a servlet-provider
         auto sp = new ServletProvider;
 
         // create a context for example servlets
         auto example = sp.addContext (new ServletContext ("/example"));
 
         // create a context for admin servlets
         auto admin = sp.addContext (new AdminContext (sp, "/admin"));
 
         // map echo requests to our echo servlet
         sp.addMapping ("/echo", sp.addServlet (new Echo, "echo", example));
 
         // point the default context to the tango help files
         sp.addContext (new ServletContext ("", "../doc/html"));
 
         // map all other requests to our file servlet
         sp.addMapping ("/", sp.addServlet (new FileServlet, "files"));
 
         // fire up a server
         testServer (sp, log);
     }
 
 The second and third autos are the big problem here. They say "create a 
 context for example servlets" and "create a context for admin servlets", 
 but nowhere in the example is it shown what a "context" is, and the type 
 "context" refers to is a mango.net.ServletContext. You wouldn't know the 
 exact type without looking up ServletProvider.addContext. The servlet 
 context is definitely something users would want to change, so while 
 it's just paper-pushing in this example it is not in real-world code.
 
 Also, from later in the same file:
 
     auto output = response.buffer;
 
  From it's name, my initial reaction would be some sort of char[] or 
 ubyte[]. Then suddenly, it's written to using the whisper syntax. In 
 retrospect, it makes sense that it's a tango.io.model.IBuffer (a class I 
 didn't even know existed, and have no idea what capabilities it has), 
 but this is the stuff I had to look up, since it's not clear from its use.
 
 I think there was a much more annoying one there, but I can't seem to 
 find it right now.
Apr 13 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Unknown W. Brackets wrote:

 Surely; but I think cases where you have to deal with another API (e.g. 
 of another library) are actually very frequent.  Documenting them in 
 your documentation may neither be prudent nor helpful.
 
 Most of the time, using auto for a return type is bad.  However, it 
 might be good - especially with a comment like this:
 
 // Version 1 and 2 return different types here.
 // Version 1 returns "Xyz" and version 2 returns "Abc".
 
 Or also:
 
 // The type returned here may change at some point.
 // It will always have a "runFromGodzilla" method, which is the only one
 // that is useful in this version of the library.
 
 And similar.  Undocumented, or poorly documented, examples are another 
 problem.  Telling me that your car runs badly without gas doesn't mean 
 tell me anything about oil.  Sure, they may both be things to improve 
 with your car.
 
 I didn't say my example was perfect, but it isn't a wrong or confusing 
 use of auto.  If I were really documenting the use of stderr, I'd 
 probably show mainly strings, much more in the way of formatting, etc. 
 Likely I would also describe why and how it is best for error messages, 
 even possibly a basic primer on how to pipe it properly.
 
 Sorry I did not give a fully developed example.  It was merely to 
 illustrate, since I'm sure anyone participating in this conversation 
 understands stderr.
 
 I frankly hate Mango/Tango's abuse of the (), and etc.  I think it makes 
 for hard to read code, confuses beginners, and isn't even clean.  I 
 realize many disagree and this is obviously a personal opinion.
 
 But I think anyone would agree that isn't a good example and auto has 
 been misused there out of laziness.  I just think that saying "auto is 
 wrong always" is very likely incorrect.
 
 -[Unknown]


I agree with everything you said here. My initial statement of "auto is 
always wrong in examples" was too broad, but that's from experience 
(mostly with Mango/Tango examples, but I don't mean to pick on them 
here) that used auto in confusing ways. I guess what I'm trying to say 
is that in examples, "air on the side of caution" and use auto only when 
the type is either very clear or has no bearing on the example.

So, basically, what you just said.
Apr 13 2008
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Well, I completely agree there - you make the good point that I meant, 
but never said...

If in doubt, don't use auto.  Only use it when it seems specifically 
right to.

I think if that rule is followed documentation will be clear.  That 
said... I'd use the same code in my own code anyway, 
documentation/example or not.

-[Unknown]


Robert Fraser wrote:

 Unknown W. Brackets wrote:

 Surely; but I think cases where you have to deal with another API 
 (e.g. of another library) are actually very frequent.  Documenting 
 them in your documentation may neither be prudent nor helpful.

 Most of the time, using auto for a return type is bad.  However, it 
 might be good - especially with a comment like this:

 // Version 1 and 2 return different types here.
 // Version 1 returns "Xyz" and version 2 returns "Abc".

 Or also:

 // The type returned here may change at some point.
 // It will always have a "runFromGodzilla" method, which is the only one
 // that is useful in this version of the library.

 And similar.  Undocumented, or poorly documented, examples are another 
 problem.  Telling me that your car runs badly without gas doesn't mean 
 tell me anything about oil.  Sure, they may both be things to improve 
 with your car.

 I didn't say my example was perfect, but it isn't a wrong or confusing 
 use of auto.  If I were really documenting the use of stderr, I'd 
 probably show mainly strings, much more in the way of formatting, etc. 
 Likely I would also describe why and how it is best for error 
 messages, even possibly a basic primer on how to pipe it properly.

 Sorry I did not give a fully developed example.  It was merely to 
 illustrate, since I'm sure anyone participating in this conversation 
 understands stderr.

 I frankly hate Mango/Tango's abuse of the (), and etc.  I think it 
 makes for hard to read code, confuses beginners, and isn't even 
 clean.  I realize many disagree and this is obviously a personal opinion.

 But I think anyone would agree that isn't a good example and auto has 
 been misused there out of laziness.  I just think that saying "auto is 
 wrong always" is very likely incorrect.

 -[Unknown]


 
 I agree with everything you said here. My initial statement of "auto is 
 always wrong in examples" was too broad, but that's from experience 
 (mostly with Mango/Tango examples, but I don't mean to pick on them 
 here) that used auto in confusing ways. I guess what I'm trying to say 
 is that in examples, "air on the side of caution" and use auto only when 
 the type is either very clear or has no bearing on the example.
 
 So, basically, what you just said.
Apr 13 2008
prev sibling next sibling parent Georg Wrede <georg nospam.org> writes:
Unknown W. Brackets wrote:

 Why?  I'm not sure I see the relevance of your analogies to the point.
 
 Surely no one shall die if they use auto.  Also, not knowing what 
 something is (which can cause you no harm directly) is very different 
 from not knowing where incoming danger might be.
 
 I think you're trying to say that having autos in examples is like 
 having mines, in that they are possible points of confusion to newcomers 
 (who will not know what those things are.)  You may also be trying to 
 say that using auto in examples teaches people to use auto more than 
 they should.


I'm ok with auto used, actually, as much as possible. I think it does 
make the code easier to read and it definitely makes a big difference 
when you later decide to change some return type.


 However, I would say that auto should not be used, except in any case 
 where the type auto is representing:
 
     - is unimportant to surrounding code (it is being paper-pushed.)
     - is unlikely to be used in any way other than the represented way 
 (e.g. has no other useful methods than are already being called.)
     - is documented in some comment in the example.
     - is an example type, with no actual importance to the example (e.g. 
 to be passed to a method that takes any value, which is what the example 
 is showing.)


Ok, I'll try to explain my point again: I do agree with the above. Now, 
the problem lies in, let's say auto was banned from examples. It hardly 
makes the _point_ of an example harder to understand, so banning auto 
should be harmless.

Now, not banning auto in examples, results in two things: only some 
people try to assess whether auto is ok for this particular example, and 
most not, and secondly, even those who try, often don't get the right 
answer, so the choice becomes arbitrary.

To see whether auto is appropriate for the example, requires several 
things *simultaneously* falling right:

  - the person has learned several languages, and is able to remember 
many of the situations where the examples in those particular languages 
have been hard to understand or have created collateral misunderstandings

  - the person has had experience /teaching/ several languages to not 
only one, but many kinds of audiences

  - the person is interested in conveying the message of the example 
beyond only the nominal issue at hand

  - the person is able to really enumerate the audiences getting exposed 
to the particular example

  - the person is able to quantify the needs of those particular audiences

  - the person has actually beta tested the example with representats of 
each audience

  - the person simply has to have the required mental cababilities for 
the above, which are separate from the ability to program in the first place

  - the person is not pressed for time (like a deadline, or other jobs 
he may be busy with), which he would need to carefully assess the merits 
or dismerits of auto in a particular example

There are other things as well, but this list gives the hint that 
judging auto for an example is truly a non-trivial task. (Of course, 
there are other judgements to be made, too, not only those pertaining to 
auto.)

A lot of textbooks are written every week. Only some of them are good. 
This illustrates that it is not easy at all to decide what and how 
should be written.


Now, banning auto from examples, both saves much hard work for the 
writer, it also makes for a consistent representation of the language.

Someone who really wants to learn fluency in a language has to (and 
will) go through masses of good source code. At the latest, at that 
point it will become evident that auto is actually used pretty much 
everywhere that it possibly can. And it should.
Apr 14 2008
prev sibling parent "Scott S. McCoy" <tag cpan.org> writes:
On Sun, 2008-04-13 at 14:42 -0700, Unknown W. Brackets wrote:

 
 I think you're trying to say that having autos in examples is like 
 having mines, in that they are possible points of confusion to
 newcomers 
 (who will not know what those things are.)  You may also be trying to 
 say that using auto in examples teaches people to use auto more than 
 they should.


I personally think auto in examples is confusing to new users, depending
on their background they may very well make unsafe assumptions about
what auto is supposed to do.

I do think auto is safe in examples, but only *after* having introduced
foreach loops as an example of how type inference works there.  I find
that's more grokable for a lot of people, after that type inference
makes a lot of sense.  And then they don't assume the "auto" keyword
works like perl's "my" or pike's "object"...they don't assume it's a
declaration of a dynamic type; since they've already had inference
explained to them.  They do then understand it's a placeholder for a
type.

That's what I'd glean, anyway, from a lot of the feedback I see about
auto.
Apr 14 2008
prev sibling parent "Hans W. Uhlig" <huhlig gmail.com> writes:
Robert Fraser wrote:

 Hans W. Uhlig wrote:

 I have been reading through the specification and playing with D more 
 and more, what is the purpose of auto. I can understand in languages 
 with scalar types handling datatypes on assignment but on a strictly 
 typed language like C or D when would auto(as a variable declaration) 
 provide more useful functionality then it removes from readability.

 When would this be useful rather then simply specifying the type?


 
 I want to (someday, not any time soon) add a feature to Descent whereby 
 "auto" can be converted to the actual type automatically throughout a 
 source file. That way, you can get the advantages of less typing (as in 
 "Punch the keys for God's sake", not "int vs. long") while still getting 
 the readability after the refactoring.


This seemed to me like the better method of handling this rather then a 
compiler based fill in.
Apr 18 2008