View mode: basic / threaded / horizontal-split · Log in · Help
March 10, 2006
I don't like auto. (the auto-typing I mean)
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.)
March 11, 2006
Re: I don't like auto. (the auto-typing I mean)
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.
March 11, 2006
Re: I don't like auto. (the auto-typing I mean)
"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.
March 11, 2006
Re: I don't like auto. (the auto-typing I mean)
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..
March 11, 2006
Re: I don't like auto. (the auto-typing I mean)
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
March 11, 2006
Re: I don't like auto. (the auto-typing I mean)
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
March 11, 2006
Re: I don't like auto. (the auto-typing I mean)
"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
March 11, 2006
Re: I don't like auto. (the auto-typing I mean)
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
March 12, 2006
Re: I don't like auto. (the auto-typing I mean)
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.
March 12, 2006
Re: I don't like auto. (the auto-typing I mean)
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.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home