auto, var, raii,scope, banana

[Regan Heath]

On Tue, 25 Jul 2006 23:28:24 -0400, Chad J  
<gamerChad at _spamIsBad_gmail.com> wrote:
> Regan Heath wrote:
>>   I say lets keep 'auto' for auto type inference (for the reasons you  
>> and  Don mention)
>>  I like the use of scope at class decl. But, I prefer the no keyword   
>> approach at instantiation. So, allow me to suggest this as a 3rd option.
>>  - 'scope' at class decl.
>> - no keyword at instatiation.
>>  Reasoning:
>>  'new' implies heap allocation to me. It would be beneficial to allow  
>> the  compiler to allocate an RAII type in any way it wants, perhaps  
>> stack  allocating it. Removing 'new' removes the implied heap  
>> allocation allowing  the compiler to allocate however it likes.
>>
>
> I disagree.
>
> If you want the compiler to be able to optimize by using stack  
> allocation instead of heap allocation, then let it do that with the new  
> keyword.

You miss-understand. I don't want stack allocation at all. I'm saying 2  
things:

1. 'new' implies heap allocation
2. lack of 'new' implies _nothing_ about allocation.

The result of which is that the compiler is not _required_ to heap  
allocate but can allocate in some other fashion.

> I'm assuming the program's behaviour would be the same in either case,  
> so it wouldn't matter to me.
>
> If you want stack allocation then how about
> scope A a = A();
>
> It keeps the concepts of scope and allocation seperate.

It's no different to this:

A a = A();

which says _nothing_ about allocation. It implies only that 'a' will be  
collected at the end of scope.
The compiler is FREE to allocate however it wants. That _may_ be stack  
allocation, it _may_ not.

In comparison this:

A a = new A();

currently 'implies' heap allocation.

That's all I was saying. I'm not suggesting stack allocation, I'm  
suggesting that removing 'new' allows the compiler to allocate however it  
wants.

You're suggesting 'new' could allocate on the stack, I think that would be  
unexpected to say the least.

> Scope is not allocation.

Correct. I never said it was. The ability to stack allocate is a by  
product of removing 'new' nothing else.

>> I don't see the utility in static opCall, I say abolish/remove it.   
>> Non-static opCall on the other hand can be quite useful.
>>  Regan
>
> Please don't abolish/remove it.  At least not until you have convinced  
> me that it is totally useless.

Convince you.. I don't have to convince you, only Walter.
Likewise you have to convince Walter.
;0)

> I really don't like the idea of dropping a language feature just for the  
> sake of having a particular syntax that, IMO, is not intuitive.

It's the same syntax you see in C++ for a class that has it's destructor  
called at the end of the scope. That, to me, makes it intuitive. For what  
reason do you find it un-intuitive?

>  From my previous post about this:
>> I like being able to use types as functions.
>> Here's one example where I do something similar to what you'd use  
>> nested functions for, but better - my forward referencing woes go away.
>>  class F
>> {
>>     int result;
>>     int tempVar1;
>>      static int opCall( int x )
>>     {
>>         F f = new F(x);
>>         int result = f.result;
>>         delete f;
>>         return result;
>>     }
>>      this( int x )
>>     {
>>         internalFunc1();
>>         // do stuff
>>     }
>>      private void internalFunc1()
>>     {
>>         if ( maybe )
>>             internalFunc2();
>>         else return;
>>     }
>>      private void internalFunc2()
>>     {
>>         if ( maybe )
>>             internalFunc1();
>>         else return;
>>     }
>> }
>>  void main()
>> {
>>     int x = 42;
>>     x = F(x);
>> }
>>  Under the hood, it may also behave differently than nested functions,  
>> which could be advantageous.  I'm not sure that it is advantageous, but  
>> options are always nice.
>>  That and you can make nice syntax sugars for alternative memory  
>> management methods like freelists, without messing with overriding  
>> 'new()'.

What's the point of using static opCall here, as opposed to a normal  
static method or even a free function?
What problem does it solve?
What new technique or method does it allow?

> I do like using the scope keyword for this btw.  It seems quite  
> consistant with D's meaning of 'scope'.

It's not bad but it's my 2nd choice currently.

Regan