www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - I don't like auto. (the auto-typing I mean)

reply "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.)
Mar 10 2006
next sibling parent 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.
Mar 10 2006
prev sibling next sibling parent "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.
Mar 10 2006
prev sibling next sibling parent "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..
Mar 10 2006
prev sibling next sibling parent reply 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
Mar 11 2006
next sibling parent 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
Mar 11 2006
prev sibling parent reply "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
Mar 11 2006
parent reply 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



 Mar 11 2006



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



 Mar 11 2006



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



 Mar 11 2006



prev sibling  parent reply "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. 



 Mar 13 2006



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



 Mar 13 2006