Jump to page: 1 2
Thread overview
I don't like auto. (the auto-typing I mean)
Mar 11, 2006
Hasan Aljudy
Mar 11, 2006
Ameer Armaly
Mar 11, 2006
Chris Miller
Mar 11, 2006
Oskar Linde
Mar 11, 2006
Kyle Furlong
Mar 11, 2006
Ameer Armaly
Mar 11, 2006
Kevin Bealer
Mar 13, 2006
Lionello Lunesu
March 10, 2006
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
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
"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
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
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
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
"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
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
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
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