• Jarrett Billingsley (25/25) Mar 10 2006 More and more I see D code strewn with
• Hasan Aljudy (5/45) Mar 10 2006 Yeah. auto can make things very confusing.
• Ameer Armaly (7/32) Mar 10 2006 I really think this comes down to a matter of common sense; people who w...
• Chris Miller (5/14) Mar 10 2006 Before this auto I had a solution:
• Oskar Linde (13/30) Mar 11 2006 Both C and C++ are full of unnamed temporaries whose types get inferred
• Kyle Furlong (2/41) Mar 11 2006 Good point
• Ameer Armaly (4/36) Mar 11 2006 Since it's obviously something we don't want, just because it exists doe...
• Kevin Bealer (18/30) Mar 11 2006 I disagree - there are times when I *do* want exactly that behavior. Le...
• Sebastián E. Peyrott (7/7) Mar 11 2006 FWIW, I think Sean made a valid point. It should be possible to infer th...
• Sebastián E. Peyrott (4/11) Mar 11 2006 OMG, I meant "break"...*shoots himself*
• Lionello Lunesu (6/8) Mar 13 2006 It's NOT "called auto". "auto" is for RAII, ie. destruction on scope exi...
• Jarrett Billingsley (4/9) Mar 13 2006 THIS HAS BEEN BEATEN TO DEATH and I don't really care about it on this

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

More and more I see D code strewn with

auto someVariable = someExpression();

I don't like this.  A bit.

Everyone seems to be treating auto like it's the best damn thing to come out 
in the language in a long time.  Now in some cases, it's really obvious what 
the type is, and sometimes saves a lot of typing:

auto w = new ClassName();
auto x = SomeReallyLongClassName.EnumType.Value;
auto y = SomeReallyUglyTemplate!(with, three, arguments);

That's cool.

But is this really necessary:

auto z = 5;

Do I know what z is?  Not really.  I have to look up the integer literal 
deduction rules to find out.  It's an int, but what about when the literals 
get bigger?  Are you so sure what type it is?

And then there's things like

auto fork = someFunction();

Oh boy.  What type is it now?  I have to look up someFunction in the docs, 
or if there are no docs, in the code itself.  What module was someFunction 
in again?  Hmm....  where is it...  wasted time.

Since this undeniably has some use, I can't say get rid of it.  But could we 
practice some restraint?  I'd say don't use auto unless it's really obvious 
what type the variable is.

(And by the way, I think it's dumb that it's called auto and also think it 
should be called var.) 

Hasan Aljudy <hasan.aljudy gmail.com> writes:

Jarrett Billingsley wrote:
 More and more I see D code strewn with
 
 auto someVariable = someExpression();
 
 I don't like this.  A bit.
 
 Everyone seems to be treating auto like it's the best damn thing to come out 
 in the language in a long time.  Now in some cases, it's really obvious what 
 the type is, and sometimes saves a lot of typing:
 
 auto w = new ClassName();
 auto x = SomeReallyLongClassName.EnumType.Value;
 auto y = SomeReallyUglyTemplate!(with, three, arguments);
 
 That's cool.
 
 But is this really necessary:
 
 auto z = 5;
 
 Do I know what z is?  Not really.  I have to look up the integer literal 
 deduction rules to find out.  It's an int, but what about when the literals 
 get bigger?  Are you so sure what type it is?
 
 And then there's things like
 
 auto fork = someFunction();
 
 Oh boy.  What type is it now?  I have to look up someFunction in the docs, 
 or if there are no docs, in the code itself.  What module was someFunction 
 in again?  Hmm....  where is it...  wasted time.
 
 Since this undeniably has some use, I can't say get rid of it.  But could we 
 practice some restraint?  I'd say don't use auto unless it's really obvious 
 what type the variable is.
 
 (And by the way, I think it's dumb that it's called auto and also think it 
 should be called var.) 
 
 

Yeah. auto can make things very confusing.
I've been using it only because I'm too lazy to type some long class name.

It doesn't help readability at all!! I sometimes forget what the type is 
supposed to be when I read code that I've written myself.

"Ameer Armaly" <ameer_armaly hotmail.com> writes:

"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:dut3aq$2vlp$1 digitaldaemon.com...
 More and more I see D code strewn with

 auto someVariable = someExpression();

 I don't like this.  A bit.

 Everyone seems to be treating auto like it's the best damn thing to come 
 out in the language in a long time.  Now in some cases, it's really 
 obvious what the type is, and sometimes saves a lot of typing:

 auto w = new ClassName();
 auto x = SomeReallyLongClassName.EnumType.Value;
 auto y = SomeReallyUglyTemplate!(with, three, arguments);

 That's cool.

 But is this really necessary:

 auto z = 5;

 Do I know what z is?  Not really.  I have to look up the integer literal 
 deduction rules to find out.  It's an int, but what about when the 
 literals get bigger?  Are you so sure what type it is?

 And then there's things like

 auto fork = someFunction();

 Oh boy.  What type is it now?  I have to look up someFunction in the docs, 
 or if there are no docs, in the code itself.  What module was someFunction 
 in again?  Hmm....  where is it...  wasted time.

I really think this comes down to a matter of common sense; people who want 
to write readable code will use auto only when it's necessary; in my opinion 
that's not too often.
 Since this undeniably has some use, I can't say get rid of it.  But could 
 we practice some restraint?  I'd say don't use auto unless it's really 
 obvious what type the variable is.

 (And by the way, I think it's dumb that it's called auto and also think it 
 should be called var.)

I agree that it shouldn't be called auto (auto what?) but var doesn't seem 
to sound right either; it may come down to guess-the-keyword. 

"Chris Miller" <chris dprogramming.com> writes:

On Fri, 10 Mar 2006 18:49:46 -0500, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:

 More and more I see D code strewn with

 auto someVariable = someExpression();

 I don't like this.  A bit.

 Everyone seems to be treating auto like it's the best damn thing to come  
 out
 in the language in a long time.  Now in some cases, it's really obvious  
 what
 the type is, and sometimes saves a lot of typing:

 auto w = new ClassName();

Before this auto I had a solution:
    MySuperLongClassName foo = new typeof(foo);
at least things make sense..

Oskar Linde <olREM OVEnada.kth.se> writes:

Jarrett Billingsley wrote:

 More and more I see D code strewn with
 
 auto someVariable = someExpression();
 
 I don't like this.  A bit.
 
 Everyone seems to be treating auto like it's the best damn thing to come
 out
 in the language in a long time.  Now in some cases, it's really obvious
 what the type is, and sometimes saves a lot of typing:
 

[snip]
 
 auto fork = someFunction();
 
 Oh boy.  What type is it now?  I have to look up someFunction in the docs,
 or if there are no docs, in the code itself.  What module was someFunction
 in again?  Hmm....  where is it...  wasted time.

Both C and C++ are full of unnamed temporaries whose types get inferred
automatically. Compare the above auto statement to:

someOtherFunction(someFunction());

How do you now know the type of someFunction()?

I'm sure you are not proposing that everyone should write:

someOtherFunction((float)someFunction());

So why is this any different from:

auto fork = someFunction();
someOtherFunction(fork);

?

/Oskar

Kyle Furlong <kylefurlong gmail.com> writes:

Oskar Linde wrote:
 Jarrett Billingsley wrote:
 
 More and more I see D code strewn with

 auto someVariable = someExpression();

 I don't like this.  A bit.

 Everyone seems to be treating auto like it's the best damn thing to come
 out
 in the language in a long time.  Now in some cases, it's really obvious
 what the type is, and sometimes saves a lot of typing:

 [snip]
 auto fork = someFunction();

 Oh boy.  What type is it now?  I have to look up someFunction in the docs,
 or if there are no docs, in the code itself.  What module was someFunction
 in again?  Hmm....  where is it...  wasted time.

 
 Both C and C++ are full of unnamed temporaries whose types get inferred
 automatically. Compare the above auto statement to:
 
 someOtherFunction(someFunction());
 
 How do you now know the type of someFunction()?
 
 I'm sure you are not proposing that everyone should write:
 
 someOtherFunction((float)someFunction());
 
 So why is this any different from:
 
 auto fork = someFunction();
 someOtherFunction(fork);
 
 ?
 
 /Oskar

Good point

"Ameer Armaly" <ameer_armaly hotmail.com> writes:

"Oskar Linde" <olREM OVEnada.kth.se> wrote in message 
news:duu0t3$1rqc$1 digitaldaemon.com...
 Jarrett Billingsley wrote:

 More and more I see D code strewn with

 auto someVariable = someExpression();

 I don't like this.  A bit.

 Everyone seems to be treating auto like it's the best damn thing to come
 out
 in the language in a long time.  Now in some cases, it's really obvious
 what the type is, and sometimes saves a lot of typing:

 [snip]
 auto fork = someFunction();

 Oh boy.  What type is it now?  I have to look up someFunction in the 
 docs,
 or if there are no docs, in the code itself.  What module was 
 someFunction
 in again?  Hmm....  where is it...  wasted time.

 Both C and C++ are full of unnamed temporaries whose types get inferred
 automatically. Compare the above auto statement to:

 someOtherFunction(someFunction());

 How do you now know the type of someFunction()?

 I'm sure you are not proposing that everyone should write:

 someOtherFunction((float)someFunction());

 So why is this any different from:

 auto fork = someFunction();
 someOtherFunction(fork);

 ?

Since it's obviously something we don't want, just because it exists doesn't 
mean we should compound the problem by making it even more common.
 /Oskar 

Kevin Bealer <Kevin_member pathlink.com> writes:

In article <duugks$2qo3$1 digitaldaemon.com>, Ameer Armaly says...

..
 someOtherFunction((float)someFunction());

 So why is this any different from:

 auto fork = someFunction();
 someOtherFunction(fork);

 ?

Since it's obviously something we don't want, just because it exists doesn't 
mean we should compound the problem by making it even more common.
 /Oskar 


I disagree - there are times when I *do* want exactly that behavior.  Lets say I
have a group of PrintObject() methods that handle the different types I use in
my program.

Then I can do this:

void foo()
{
auto f = someFunction();
PrintObject(f);
}

My code will work even if I change someFunction() to return a different type.

This is really, really useful when writing templates - but I would argue that
it's a good thing even here.

This is one of the things that makes foreach() so useful - I don't need to know
whose opApply() method gets called, if I take a container as an argument to a
template - it can just take *any* container and iterate over it.

Kevin

Sebastián E. Peyrott <as7cf yahoo.com> writes:

FWIW, I think Sean made a valid point. It should be possible to infer the type
of variable in its declaration and at the same time declare it as RAII object.
IMO, the worst thing about this are the implications behind the solution. How
much code would brake if the keyword were to be changed for one or both cases?
If there's going to be a change, now may be the best time to do it...

--
Sebastián.

Sebastián E. Peyrott <as7cf yahoo.com> writes:

In article <dv09h9$2b7d$1 digitaldaemon.com>, Sebastián E. Peyrott says...
FWIW, I think Sean made a valid point. It should be possible to infer the type
of variable in its declaration and at the same time declare it as RAII object.
IMO, the worst thing about this are the implications behind the solution. How
much code would brake if the keyword were to be changed for one or both cases?
If there's going to be a change, now may be the best time to do it...

--
Sebastián.

OMG, I meant "break"...*shoots himself*

--
Sebastián.

"Lionello Lunesu" <lio remove.lunesu.com> writes:

 (And by the way, I think it's dumb that it's called auto and also think it 
 should be called var.)

It's NOT "called auto". "auto" is for RAII, ie. destruction on scope exit. 
"auto" is just one way for the compiler to recognize a declaration. There 
are other keywords that trigger this (like "static"). Check my post in the 
"auto -> auto & var" thread, or do a search and find Walter's response to 
this issue.

L. 

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Lionello Lunesu" <lio remove.lunesu.com> wrote in message 
news:dv3nac$2h4j$1 digitaldaemon.com...
 It's NOT "called auto". "auto" is for RAII, ie. destruction on scope exit. 
 "auto" is just one way for the compiler to recognize a declaration. There 
 are other keywords that trigger this (like "static"). Check my post in the 
 "auto -> auto & var" thread, or do a search and find Walter's response to 
 this issue.

THIS HAS BEEN BEATEN TO DEATH and I don't really care about it on this 
thread.