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

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>

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?

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

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.

"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
    }

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

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.

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>

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?