auto, var, raii,scope, banana

[Chad J]

Regan Heath wrote:
> 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.
> 

That's actually what I thought you meant, though I am probably creating 
a false dichotomy - stack vs heap.

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

I did intend to convey that the 'new' keyword could have this ambiguity, 
but under one condition - that it not change the behaviour of the program.

If you need something more hardcore than that, something that causes 
undefined behaviour, I ask that it not be at the expense of current 
features.

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

True, you are not required to convince me of anything.  It was a 
request.  You seem to have some good reasons for prefering this syntax, 
so please enlighten me.  It's kind of a helpfulness thing; saves me some 
grief from having a feature removed that I like.  If I agree with you, 
there is no grief, only joy :).

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

I do not originate from C++, more like C#/Java.  I do know some C++ 
though, and most of my experiences with it have been frustrating bad 
ones.  Anyhow, before I go on that tangent, not everyone is a C++ 
programmer.

I say it's unintuitive because it is implicit - it provides no explicit 
information to the reader.  Since the absence of anything explicit gives 
no information, you might as well use the keyword asdfqwertok.  Even 
that gives more information than a blank space.  For a D newbie reading 
code, having a keyword is good because it gives them a keyword to search 
the spec for.  Better yet if it is 'scope', because that gives them an 
idea of where to look.  This is also one of those things that is used 
seldom enough that the succinctness gained from implicit things is only 
slightly helpful.

In a nutshell: assume a programmer of undefined language background, and 
I believe 'scope' will be much more informative (and therefore 
intuitive) than a blank space.

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

Why not a normal static method? - implementation hiding.
Why not a free function? - I'm assuming you mean a normal function 
declared at module scope.  It allows you to have multiple functions with 
access to the same non-static variables (member variables).  I suppose 
this is usually accomplished with nested functions, or OOP that can't do 
implementation hiding.  Doing it this way allows me to avoid forward 
referencing issues and also gives me more options about how my code 
behaves.

> What problem does it solve?

Annoyance from forward referencing in nested functions, but that's just 
one.  Maybe a small degree of implementation hiding for memory 
management, though I haven't tried this enough to demonstrate it.  It is 
not really a solution.  It is a technique, a syntax sugar, or just an 
easy way to get D to do things you would not ordinarily make it do.

> What new technique or method does it allow?

Multiple functions using the same non-static variables with no need for 
forward referencing and possible code behaviour tweaks, etc yadda yadda. 
  I admit it's not horribly important, but I don't think that this 
choice of syntax is either.  Most of all, I like it.

*sigh* those were long winded answers, sorry about that.

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

Care to explain why static opCall is a hack and/or not useful outside of 
RAII or struct constructors?