auto -> auto & var

[Unknown W. Brackets]

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