www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - auto -> auto & var

reply Kramer <Kramer_member pathlink.com> writes:
I keep tripping myself over the double meaning of auto.  I know it shouldn't be
that difficult to remember that auto means type inference and also stack
allocation/RAII, but does it have to be that way?

I don't know if anyone else agrees, but I wouldn't mind seeing auto's uses
properly split:

var -> type inference
auto -> RAII

I remember it also being mentioned that the syntax could possibly change to
allow classes to be created on the stack like so:

Class c = new Class() // heap
Class c = Class() // stack

But if auto can be split so it's meaning isn't overloaded, I think then auto
would do just fine for this scenario.

The specs state "An implicit type inference for a class reference is not an auto
declaration, even if the auto storage class is used".  That's just one more
thing to remember and confuse a newbie.

Sorry if this sounds like a rant (it was more of a hasty frustration) and
everyone is ok with auto as-is; I can certainly live just fine with it.  It just
seems more natural *not* overloaded.

-Kramer
Mar 10 2006
next sibling parent David Gileadi <David_member pathlink.com> writes:
I'm a lurker in this NG; I don't usually join in but as a newbie to D this seems
to be one of the few inelegant things about it.  It's not a deal-breaker, just
confusing and a bit annoying.

The proposal below has been suggested before.  I think it's a good one, and add
my vote to it.

-Dave

In article <duspas$2dfo$1 digitaldaemon.com>, Kramer says...

I keep tripping myself over the double meaning of auto.  I know it shouldn't be
that difficult to remember that auto means type inference and also stack
allocation/RAII, but does it have to be that way?

I don't know if anyone else agrees, but I wouldn't mind seeing auto's uses
properly split:

var -> type inference
auto -> RAII

I remember it also being mentioned that the syntax could possibly change to
allow classes to be created on the stack like so:

Class c = new Class() // heap
Class c = Class() // stack

But if auto can be split so it's meaning isn't overloaded, I think then auto
would do just fine for this scenario.

The specs state "An implicit type inference for a class reference is not an auto
declaration, even if the auto storage class is used".  That's just one more
thing to remember and confuse a newbie.

Sorry if this sounds like a rant (it was more of a hasty frustration) and
everyone is ok with auto as-is; I can certainly live just fine with it.  It just
seems more natural *not* overloaded.

-Kramer
Mar 10 2006
prev sibling next sibling parent reply Nils Hensel <nils.hensel web.de> writes:
Kramer schrieb:

 I don't know if anyone else agrees, but I wouldn't mind seeing auto's uses
 properly split:
 
 var -> type inference
 auto -> RAII


Certainly gets my vote.

Nils
Mar 10 2006
parent reply Kramer <Kramer_member pathlink.com> writes:
In article <dussar$2ihn$1 digitaldaemon.com>, Nils Hensel says...

Kramer schrieb:

 I don't know if anyone else agrees, but I wouldn't mind seeing auto's uses
 properly split:
 
 var -> type inference
 auto -> RAII


Certainly gets my vote.

Nils



Or another alternative to minimize disruption for current auto use for type
inference:

auto -> type inference
local -> RAII (I think I've seen this proposed before for RAII as well before)
Mar 10 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 11 Mar 2006 09:20:25 +1100, Kramer <Kramer_member pathlink.com>  
wrote:


 In article <dussar$2ihn$1 digitaldaemon.com>, Nils Hensel says...

 Kramer schrieb:

 I don't know if anyone else agrees, but I wouldn't mind seeing auto's  
 uses
 properly split:

 var -> type inference
 auto -> RAII


 Certainly gets my vote.

 Nils



 Or another alternative to minimize disruption for current auto use for  
 type
 inference:

 auto -> type inference
 local -> RAII (I think I've seen this proposed before for RAII as well  
 before)


I don't care so long as 'auto' is not used to mean both. This is just such  
an obvious wart in the language. Currently the language prevents one from  
declaring a type-infered variable that is also RAII.



-- 
Derek Parnell
Melbourne, Australia
Mar 10 2006
parent reply Tom <Tom_member pathlink.com> writes:
In article <op.s5732cfb6b8z09 ginger>, Derek Parnell says...

On Sat, 11 Mar 2006 09:20:25 +1100, Kramer <Kramer_member pathlink.com>  
wrote:


 In article <dussar$2ihn$1 digitaldaemon.com>, Nils Hensel says...

 Kramer schrieb:

 I don't know if anyone else agrees, but I wouldn't mind seeing auto's  
 uses
 properly split:

 var -> type inference
 auto -> RAII


 Certainly gets my vote.

 Nils



 Or another alternative to minimize disruption for current auto use for  
 type
 inference:

 auto -> type inference
 local -> RAII (I think I've seen this proposed before for RAII as well  
 before)


I don't care so long as 'auto' is not used to mean both. This is just such  
an obvious wart in the language. Currently the language prevents one from  
declaring a type-infered variable that is also RAII.


Agree :o (I didn't realize that before). Serious issue.

Tom;
Mar 10 2006
parent Sebastián E. Peyrott <as7cf yahoo.com> writes:
In article <dutfq6$iul$1 digitaldaemon.com>, Tom says...

In article <op.s5732cfb6b8z09 ginger>, Derek Parnell says...

On Sat, 11 Mar 2006 09:20:25 +1100, Kramer <Kramer_member pathlink.com>  
wrote:


 In article <dussar$2ihn$1 digitaldaemon.com>, Nils Hensel says...

 Kramer schrieb:

 I don't know if anyone else agrees, but I wouldn't mind seeing auto's  
 uses
 properly split:

 var -> type inference
 auto -> RAII


 Certainly gets my vote.

 Nils



 Or another alternative to minimize disruption for current auto use for  
 type
 inference:

 auto -> type inference
 local -> RAII (I think I've seen this proposed before for RAII as well  
 before)


I don't care so long as 'auto' is not used to mean both. This is just such  
an obvious wart in the language. Currently the language prevents one from  
declaring a type-infered variable that is also RAII.


Agree :o (I didn't realize that before). Serious issue.

Tom;


I just realized I posted something meant for this thread somewhere else...argh,
I'm terribly sorry. Here it goes:

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 break 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
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Here's what I hate about var: I use JavaScript a lot (this happens when 
you make interactive websites for a living.)  What do you mean, that's 
not a reason?

Sure it is.  In JavaScript and other scripting languages, this would be 
valid:

var x;

// Okay, let's make it an array!
x = new Array(1, 2, 3);

// Actually, you know what, I take that back.
x = "1,2,3";

// Come to think, this might be better...
x = {0: 1, 1: 2, 2: 3};

// No, no, actually it just needs one.  How clueless of me.
x = 1;

This is not at all so of the same feature in D; but this is what var 
means to me.  Not just from scripting languages, but from everything to 
do with "var".  I really don't think mine is an uncommon perspective.

Now, I can't say I like auto all that much either, but at least I'd 
never for a moment think the above code should work with "auto".  And 
it's really not that bad, I mean honestly...

Also I've never seen Walter give any support to this:

Class c = Class();

Instead, I read what Walter had posted as meaning that these:

static i = 1;
auto i = 1;
const i = 1;

Were all valid, and simply all meant type inference.  This gave me the, 
perhaps mistaken, impression that auto ALWAYS means RAII.  Or at least 
that is his future intention.  Perhaps I misunderstood.

This would mean that there's no way to infer the type of a variable you 
don't want on the stack, which I don't honestly consider entirely 
desirable.  Perhaps "local" would make more sense.  But nor var.  Please 
not var.

-[Unknown]



 I keep tripping myself over the double meaning of auto.  I know it shouldn't be
 that difficult to remember that auto means type inference and also stack
 allocation/RAII, but does it have to be that way?
 
 I don't know if anyone else agrees, but I wouldn't mind seeing auto's uses
 properly split:
 
 var -> type inference
 auto -> RAII
 
 I remember it also being mentioned that the syntax could possibly change to
 allow classes to be created on the stack like so:
 
 Class c = new Class() // heap
 Class c = Class() // stack
 
 But if auto can be split so it's meaning isn't overloaded, I think then auto
 would do just fine for this scenario.
 
 The specs state "An implicit type inference for a class reference is not an
auto
 declaration, even if the auto storage class is used".  That's just one more
 thing to remember and confuse a newbie.
 
 Sorry if this sounds like a rant (it was more of a hasty frustration) and
 everyone is ok with auto as-is; I can certainly live just fine with it.  It
just
 seems more natural *not* overloaded.
 
 -Kramer
Mar 11 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Unknown W. Brackets wrote:

 Here's what I hate about var: I use JavaScript a lot (this happens when 
 you make interactive websites for a living.)  What do you mean, that's 
 not a reason?
 
 Sure it is.  In JavaScript and other scripting languages, this would be 
 valid:
 
 var x;
 
 // Okay, let's make it an array!
 x = new Array(1, 2, 3);
 
 // Actually, you know what, I take that back.
 x = "1,2,3";
 
 // Come to think, this might be better...
 x = {0: 1, 1: 2, 2: 3};
 
 // No, no, actually it just needs one.  How clueless of me.
 x = 1;


Breaking the unfortunate "auto" into two separate words would be very 
good. But like you say, "var" may not be a good candidate. Especially 
when a change in the language should strive to _improve_ it, and not 
merely substitute one problem for another.

Ideally a programming language should be readable without having to 
think and remember stuff (that has with the language itself to do). All 
the needed mental gymnastics should pertain to the source code itself 
and its semantics. Not to those of the language.

<stab> If we wanted to save keywords, we could surely find lots of other 
places where we could use the same word for different things, without it 
becoming awkward for the compiler. But so far we haven't done that. It 
would be just dumb. </stab>
Mar 17 2006
next sibling parent reply james <james_member pathlink.com> writes:
In article <441B161B.4010109 nospam.org>, Georg Wrede says...

Unknown W. Brackets wrote:

 Here's what I hate about var: I use JavaScript a lot (this happens when 
 you make interactive websites for a living.)  What do you mean, that's 
 not a reason?
 
 Sure it is.  In JavaScript and other scripting languages, this would be 
 valid:
 
 var x;
 
 // Okay, let's make it an array!
 x = new Array(1, 2, 3);
 
 // Actually, you know what, I take that back.
 x = "1,2,3";
 
 // Come to think, this might be better...
 x = {0: 1, 1: 2, 2: 3};
 
 // No, no, actually it just needs one.  How clueless of me.
 x = 1;


Breaking the unfortunate "auto" into two separate words would be very 
good. But like you say, "var" may not be a good candidate. Especially 
when a change in the language should strive to _improve_ it, and not 
merely substitute one problem for another.

Ideally a programming language should be readable without having to 
think and remember stuff (that has with the language itself to do). All 
the needed mental gymnastics should pertain to the source code itself 
and its semantics. Not to those of the language.

<stab> If we wanted to save keywords, we could surely find lots of other 
places where we could use the same word for different things, without it 
becoming awkward for the compiler. But so far we haven't done that. It 
would be just dumb. </stab>


What is the current status of this issue? What is Walters thinking?
Mar 17 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
james wrote:

 In article <441B161B.4010109 nospam.org>, Georg Wrede says...
 

 Unknown W. Brackets wrote:
 

 Here's what I hate about var: I use JavaScript a lot (this
 happens when you make interactive websites for a living.)  What
 do you mean, that's not a reason?
 
 Sure it is.  In JavaScript and other scripting languages, this
 would be valid:
 
 var x;
 
 // Okay, let's make it an array! x = new Array(1, 2, 3);
 
 // Actually, you know what, I take that back. x = "1,2,3";
 
 // Come to think, this might be better... x = {0: 1, 1: 2, 2: 3};
 
 
 // No, no, actually it just needs one.  How clueless of me. x =
 1;


 
 Breaking the unfortunate "auto" into two separate words would be
 very good. But like you say, "var" may not be a good candidate.
 Especially when a change in the language should strive to _improve_
 it, and not merely substitute one problem for another.
 
 Ideally a programming language should be readable without having to
  think and remember stuff (that has with the language itself to
 do). All the needed mental gymnastics should pertain to the source
 code itself and its semantics. Not to those of the language.
 
 <stab> If we wanted to save keywords, we could surely find lots of
 other places where we could use the same word for different things,
 without it becoming awkward for the compiler. But so far we haven't
 done that. It would be just dumb. </stab>


 
 
 What is the current status of this issue? What is Walters thinking?


IIRC, he was happy using the auto for both.
Mar 18 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Georg Wrede wrote:

 Unknown W. Brackets wrote:

 Here's what I hate about var: I use JavaScript a lot (this happens 
 when you make interactive websites for a living.)  What do you mean, 
 that's not a reason?

 Sure it is.  In JavaScript and other scripting languages, this would 
 be valid:

 var x;

 // Okay, let's make it an array!
 x = new Array(1, 2, 3);

 // Actually, you know what, I take that back.
 x = "1,2,3";

 // Come to think, this might be better...
 x = {0: 1, 1: 2, 2: 3};

 // No, no, actually it just needs one.  How clueless of me.
 x = 1;


 
 Breaking the unfortunate "auto" into two separate words would be very 
 good. But like you say, "var" may not be a good candidate. Especially 
 when a change in the language should strive to _improve_ it, and not 
 merely substitute one problem for another.


For what it's worth, the next iteration of C++ will add 'auto' as an 
auto-type keyword, so for the sake of consistency I think 'var' should 
not be used in D.


Sean
Mar 17 2006
parent "Chris Miller" <chris dprogramming.com> writes:
On Fri, 17 Mar 2006 15:54:09 -0500, Sean Kelly <sean f4.ca> wrote:


 Georg Wrede wrote:

 Unknown W. Brackets wrote:

 Here's what I hate about var: I use JavaScript a lot (this happens  
 when you make interactive websites for a living.)  What do you mean,  
 that's not a reason?

 Sure it is.  In JavaScript and other scripting languages, this would  
 be valid:

 var x;

 // Okay, let's make it an array!
 x = new Array(1, 2, 3);

 // Actually, you know what, I take that back.
 x = "1,2,3";

 // Come to think, this might be better...
 x = {0: 1, 1: 2, 2: 3};

 // No, no, actually it just needs one.  How clueless of me.
 x = 1;


  Breaking the unfortunate "auto" into two separate words would be very  
 good. But like you say, "var" may not be a good candidate. Especially  
 when a change in the language should strive to _improve_ it, and not  
 merely substitute one problem for another.


 For what it's worth, the next iteration of C++ will add 'auto' as an  
 auto-type keyword, so for the sake of consistency I think 'var' should  
 not be used in D.



C-descendant trend in some areas. I personally don't think var is a good  
choice, it reminds people of silly scripting languages.
Mar 19 2006
prev sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
int main()
{
	loop (int i = 0; i < 5; i++)
	{
		writefln(i);
	}

my_forever_loop:
	loop (true)
	{
		writefln("would be forever");
		break my_forever_loop;
	}

	break 0;
}

Surely the compiler would have no trouble parsing this.

-[Unknown]



 <stab> If we wanted to save keywords, we could surely find lots of other 
 places where we could use the same word for different things, without it 
 becoming awkward for the compiler. But so far we haven't done that. It 
 would be just dumb. </stab>
Mar 18 2006
prev sibling next sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Kramer wrote:

 I keep tripping myself over the double meaning of auto.  I know it shouldn't be
 that difficult to remember that auto means type inference and also stack
 allocation/RAII, but does it have to be that way?
 
 I don't know if anyone else agrees, but I wouldn't mind seeing auto's uses
 properly split:
 
 var -> type inference
 auto -> RAII
 


Yep, as I've said before, I'm also in favor of this change. (unless 
someone can come with an even better keyword for var)

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 12 2006
prev sibling parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
"Kramer" <Kramer_member pathlink.com> wrote in message 
news:duspas$2dfo$1 digitaldaemon.com...

I keep tripping myself over the double meaning of auto.  I know it 
shouldn't be
 that difficult to remember that auto means type inference and also stack
 allocation/RAII, but does it have to be that way?


Walter explained it: it does not have two meanings. The "auto" merely 
notifies the compiler (or lexer, I don't know) that it's a declaration and a 
variable name will follow.

When the compiler encounters "auto x" it knows "x" is a variable. Since 
"auto x" doesn't mention a type, it'll be derived.. Same thing for "static 
x", x must be a variable, but there's no type so it'll be derived.

L.
Mar 13 2006
next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Lionello Lunesu wrote:

 "Kramer" <Kramer_member pathlink.com> wrote in message 
 news:duspas$2dfo$1 digitaldaemon.com...
 

I keep tripping myself over the double meaning of auto.  I know it 
shouldn't be
that difficult to remember that auto means type inference and also stack
allocation/RAII, but does it have to be that way?


 
 
 Walter explained it: it does not have two meanings. The "auto" merely 
 notifies the compiler (or lexer, I don't know) that it's a declaration and a 
 variable name will follow.
 
 When the compiler encounters "auto x" it knows "x" is a variable. Since 
 "auto x" doesn't mention a type, it'll be derived.. Same thing for "static 
 x", x must be a variable, but there's no type so it'll be derived.
 
 L.


Actually there is a difference.  If I use `static x = new Foo;` then 'x' is
static.  If I 
use `const x = "abc"c;` then 'x' is const.  But if I use `auto x = new Foo;`
then 'x' is 
NOT auto.  For whatever reason, the auto attribute, when used to trigger type
inference, 
does not continue to apply to the variable, whereas the other attributes with
this 
behavior do continue to apply.

Although for the record, I'm mostly fine with using auto for this, anyhow.  I
just wonder 
how to declare an inferred variable that is also auto.  Is it `auto auto x
=...`)

-- Christopher Nicholson-Sauls
Mar 13 2006
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Lionello Lunesu wrote:

 "Kramer" <Kramer_member pathlink.com> wrote in message 
 news:duspas$2dfo$1 digitaldaemon.com...
 

 I keep tripping myself over the double meaning of auto.  I know it
  shouldn't be that difficult to remember that auto means type
 inference and also stack allocation/RAII, but does it have to be
 that way?


 
 Walter explained it: it does not have two meanings. The "auto" merely
  notifies the compiler (or lexer, I don't know) that it's a
 declaration and a variable name will follow.
 
 When the compiler encounters "auto x" it knows "x" is a variable.
 Since "auto x" doesn't mention a type, it'll be derived.. Same thing
 for "static x", x must be a variable, but there's no type so it'll be
 derived.


While Walter is right, this still _seems_ like two separate things, 
especially for those new to the language. Whether new to programming or 
just new to D.

Pascal used to make a fuss about the difference between a Function and a 
Procedure. No C programmer couldn't care less about that difference. But 
the main point is that having two separate names for [the same or 
different things, depending on who you ask], might not always be bad for 
your health.

Two separate words would ease learning D, and make it clearer which the 
programmer meant. This is especially important for expedient debugging.
Mar 17 2006
parent "John C" <johnch_atms hotmail.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:441B23AC.7050905 nospam.org...

 Lionello Lunesu wrote:

 "Kramer" <Kramer_member pathlink.com> wrote in message 
 news:duspas$2dfo$1 digitaldaemon.com...


 I keep tripping myself over the double meaning of auto.  I know it
  shouldn't be that difficult to remember that auto means type
 inference and also stack allocation/RAII, but does it have to be
 that way?


 Walter explained it: it does not have two meanings. The "auto" merely
  notifies the compiler (or lexer, I don't know) that it's a
 declaration and a variable name will follow.

 When the compiler encounters "auto x" it knows "x" is a variable.
 Since "auto x" doesn't mention a type, it'll be derived.. Same thing
 for "static x", x must be a variable, but there's no type so it'll be
 derived.


 While Walter is right, this still _seems_ like two separate things, 
 especially for those new to the language. Whether new to programming or 
 just new to D.

 Pascal used to make a fuss about the difference between a Function and a 
 Procedure. No C programmer couldn't care less about that difference. But 
 the main point is that having two separate names for [the same or 
 different things, depending on who you ask], might not always be bad for 
 your health.

 Two separate words would ease learning D, and make it clearer which the 
 programmer meant. This is especially important for expedient debugging.


There won't be a need for two keywords when Walter implements the new 
stack-allocation syntax. I think this was it:

    void main() {
        Stream theDaVinciCode = File("thedavincicode.txt");
        theDaVinciCode .readLine(); // read the first line
        // close theDaVinciCode immediately
    }
Mar 17 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 13 Mar 2006 23:03:47 +1100, Lionello Lunesu  
<lio remove.lunesu.com> wrote:


 "Kramer" <Kramer_member pathlink.com> wrote in message
 news:duspas$2dfo$1 digitaldaemon.com...

 I keep tripping myself over the double meaning of auto.  I know it
 shouldn't be
 that difficult to remember that auto means type inference and also stack
 allocation/RAII, but does it have to be that way?


 Walter explained it: it does not have two meanings. The "auto" merely
 notifies the compiler (or lexer, I don't know) that it's a declaration  
 and a
 variable name will follow.

 When the compiler encounters "auto x" it knows "x" is a variable. Since
 "auto x" doesn't mention a type, it'll be derived.. Same thing for  
 "static
 x", x must be a variable, but there's no type so it'll be derived.


This seems to be true, however the RAII behaviour is not invoked when this  
syntax is used. So how does one declare an auto-type-infered and an  
auto-RAII variable? For some example code ...

import std.stdio;
class bar
{
     this() { writefln("ctor bar"); }
     ~this(){ writefln("dtor bar"); }
}

int foo()
{
     auto bar a = new bar;
     return a.sizeof;
}

int xyz()
{
     auto a = new bar;
     return a.sizeof;
}

void main()
{
     writefln("foo: %s", foo());
     writefln("xyz: %s", xyz());
}


===========
output:

ctor bar
dtor bar
foo: 4
ctor bar
xyz: 4
dtor bar
===========

Which seems to be showing that 'auto bar a = new bar;' is needed for RAII  
behaviour and just 'auto a = new bar;' does type inference but no RAII.  
And if one uses 'auto auto a = new bar' we get the compiler error  
"redundant storage class 'auto'".

-- 
Derek Parnell
Melbourne, Australia
Mar 18 2006
parent james <james_member pathlink.com> writes:
In article <op.s6lxyol46b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...

On Mon, 13 Mar 2006 23:03:47 +1100, Lionello Lunesu  
<lio remove.lunesu.com> wrote:


 "Kramer" <Kramer_member pathlink.com> wrote in message
 news:duspas$2dfo$1 digitaldaemon.com...

 I keep tripping myself over the double meaning of auto.  I know it
 shouldn't be
 that difficult to remember that auto means type inference and also stack
 allocation/RAII, but does it have to be that way?


 Walter explained it: it does not have two meanings. The "auto" merely
 notifies the compiler (or lexer, I don't know) that it's a declaration  
 and a
 variable name will follow.

 When the compiler encounters "auto x" it knows "x" is a variable. Since
 "auto x" doesn't mention a type, it'll be derived.. Same thing for  
 "static
 x", x must be a variable, but there's no type so it'll be derived.


This seems to be true, however the RAII behaviour is not invoked when this  
syntax is used. So how does one declare an auto-type-infered and an  
auto-RAII variable? For some example code ...

import std.stdio;
class bar
{
     this() { writefln("ctor bar"); }
     ~this(){ writefln("dtor bar"); }
}

int foo()
{
     auto bar a = new bar;
     return a.sizeof;
}

int xyz()
{
     auto a = new bar;
     return a.sizeof;
}

void main()
{
     writefln("foo: %s", foo());
     writefln("xyz: %s", xyz());
}


===========
output:

ctor bar
dtor bar
foo: 4
ctor bar
xyz: 4
dtor bar
===========

Which seems to be showing that 'auto bar a = new bar;' is needed for RAII  
behaviour and just 'auto a = new bar;' does type inference but no RAII.  
And if one uses 'auto auto a = new bar' we get the compiler error  
"redundant storage class 'auto'".

-- 
Derek Parnell
Melbourne, Australia



Great example.

So with auto you can have either type inference OR raii for a particular
declaration. Why not both?
Does anyone know if this is the intended behaviour? And what is Walters thinking
on this?
Mar 19 2006