auto, var, raii,scope, banana

[Regan Heath]

>>> If they both have learning to do anyways, why not just have them learn
>>> 'scope'?
>>   Right back at ya.. why not have them both learn to omit 'new'?
>>
>
> Point being it doesn't give you the win-lose, you're still stuck with a  
> lose-lose.  If both coders have to learn, then we lose the advantage of  
> chosing this syntax to make it so C++ coders don't have to learn.

True.. however not being a C++ programmer "on a daily basis" I can't say  
for certain which of the 2 syntaxes I have given as examples of how a  
C++ programmer would do it, is the more common.

> You still have a point wrt similarity, though I dislike subtly different  
> behaviours as it can lead to bad assumptions.

Different behaviour (heap vs stack allocation) is only a problem if it  
changes the outcome of the program. heap vs stack doesn't change the  
outcome, but it might affect the speed/efficiency of the program as doing  
1,000,000 heap allocations is slower than the same number of stack ones.

Adding stack allocation to 'auto' would then be a speed optimisation.

>>  In our case, I believe the D syntax:
>>  auto A a = new A();
>>  and the C++ syntax:
>>  A a;
>>  behave almost identically. The difference being that D current does  
>> not  allocate on the stack, but, that may change and if it does they  
>> will  behave identically.
>>
>
> OK I'd like some clarification about the C++ side of things.
> It seems to me that both syntaxes such as
>
> A a = A();
>
> and
>
> A a;
>
> have been said to cause stack allocation in C++.  Is this true?

Yes, I believe so. To heap allocate you have to use 'new'. My MSDN docs  
say..

"The new operator is used to allocate objects and arrays of objects. The  
new operator allocates from a program memory area called the “free store.”  
In C, the free store is often referred to as the “heap.”"

> A a;
> Currently that is the syntax for declaring a variable.

D initialises 'a' to null.

> It will break any code that relies on 'a' being initialized to null.

No. But it will break any code which assumes it's not null, which is what  
the poor C++ programmer discovers in his/her first D program.

> If that's alright, you could change it to mean RAII/stackalloc in the  
> context of a function, but then you lose consistancy with D's practice  
> of initializing variables to knownly invalid values.

True.

A a;

would have to call the class constructor, so it would have a known 'valid'  
value instead. Likewise:'

A a = A(1,2,3);

would do the same, only this time you can pass parameters to the class  
constructor.
These two syntaxes are really one and the same.

> That does work.  Forces you to put the function outside of the class,  
> but meh, it's just aesthetics/syntax sugar.

"function outside of the class" is what I meant by "free function" .. he's  
free, not trapped in a class ;)

So.. I'm still left with little idea when someone would actually use a  
static opCall and what purpose/problem it solves (beyond being syntactic  
sugar for free functions or other static methods of a class). If it's just  
syntactic sugar _and_ we decide we like the omit 'new' syntax (doesn't  
look promising at this stage, no matter) then I would vote for static  
opCall to be removed.

Regan