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

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

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

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)

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

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;

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.

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

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

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