www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - auto, var, raii,scope, banana

reply kris <foo bar.com> writes:
Don has a good point: changing to "var" would cause conflict with 
existing variable-names.

Chad et. al. also have a good point about the conflict regarding static 
opCall() (via the lack of a "new" keyword). I suspect many people find 
the use of "new" to be indicative of allocation, and breaking this 
consistency may have a detrimental effect? Further, it was noted that a 
missing "new" can only be used at the instantiation site -- not at the 
class decl -- thus, D would be losing an existing feature.

I suspect you could count the current number of raii-class uses on a few 
hands, whereas the use of "auto" for implied-type is pretty darned 
popular -- and rightly so, since it's really very, very useful. Changing 
the raii style to use a different keyword, whilst retaining implied-type 
"auto" would be an almost imperceptible change?

Thus, it would appear to make sense to retain "auto" for implied-type, 
and introduce something *else* for automatic cleanup at end-of-scope 
(and also as a class attribute). how about reusing the "scope" keyword?

void main()
{
   auto i = 10;
   auto foo = new Foo;
   auto scope bar = new Bar;
   auto scope wumpus = new Wumpus;
}

class Foo {}

class Bar {}

scope class Wumpus {}
Jul 25 2006
next sibling parent reply Nils Hensel <nils.hensel web.de> writes:
kris schrieb:
 Don has a good point: changing to "var" would cause conflict with 
 existing variable-names.
I'm sorry but I don't believe there are many programmers out there actually using something as undescriptive as "var" as a regular identifier. I also strongly believe that no one should. It's the implication of a maintenance nightmare. I don't intend to insult Don in any way but it's a horrible practice IMNSHO that should not be preserved. So let's not focus on some odd minority but rather on the wide use of "var" in the context of type inference and dynamic typing. Also I don't think that it's a good habit to be looking at how C++ does something unless one is looking for a bad example. My main reason for interest in D is because personally I'm fed up with C++ and consider it an abomination and a major PITA. Just my 0.02 EUROs, Nils
Jul 25 2006
next sibling parent kris <foo bar.com> writes:
Nils Hensel wrote:
 kris schrieb:
 
 Don has a good point: changing to "var" would cause conflict with 
 existing variable-names.
I'm sorry but I don't believe there are many programmers out there actually using something as undescriptive as "var" as a regular identifier. I also strongly believe that no one should. It's the implication of a maintenance nightmare. I don't intend to insult Don in any way but it's a horrible practice IMNSHO that should not be preserved. So let's not focus on some odd minority but rather on the wide use of "var" in the context of type inference and dynamic typing. Also I don't think that it's a good habit to be looking at how C++ does something unless one is looking for a bad example. My main reason for interest in D is because personally I'm fed up with C++ and consider it an abomination and a major PITA. Just my 0.02 EUROs, Nils
Well, it would have notable impact on existing code to change auto to var. They're at least equally clear in my view, so it would come down to a question of impact upon existing code. What's more important is the clarification of what "auto" means. Right now, it's somewhat confused (with raii). If we instead use "scope" to indicate raii, that confusion just goes away. Besides, "scope" is a fine attribute for things that are "scoped" :)
Jul 25 2006
prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 25 Jul 2006 20:14:52 +0200, Nils Hensel <nils.hensel web.de> wrote:
 kris schrieb:
 Don has a good point: changing to "var" would cause conflict with  
 existing variable-names.
I'm sorry but I don't believe there are many programmers out there actually using something as undescriptive as "var" as a regular identifier. I also strongly believe that no one should. It's the implication of a maintenance nightmare. I don't intend to insult Don in any way but it's a horrible practice IMNSHO that should not be preserved.
I don't use "var" specifically but I have been known to use tmp, x, y, i, j, p, s, n, .. for all my temporary and/or meaningless variables. They typically have a short scope life and I can't see a problem with this practice.
 So let's not focus on some odd minority but rather on the wide use of  
 "var" in the context of type inference and dynamic typing.
I think Kris's point is that of the two choices 'var' and 'auto' the latter is less likely to annoy someone by colliding with existing user variables. The point is valid so long as the group of 'var' users is bigger than the group of 'auto' users, even if both groups are small.
 Also I don't think that it's a good habit to be looking at how C++ does  
 something unless one is looking for a bad example. My main reason for  
 interest in D is because personally I'm fed up with C++ and consider it  
 an abomination and a major PITA.
C++ may be an abomination but it does have 'market' dominance. You have to ask 'why'. You should learn from your 'enemies' ;) Regan
Jul 25 2006
parent reply Nils Hensel <nils.hensel web.de> writes:
Regan Heath schrieb:
 I don't use "var" specifically but I have been known to use tmp, x, y, 
 i, j, p, s, n, .. for all my temporary and/or meaningless variables. 
 They typically have a short scope life and I can't see a problem with 
 this practice.
I don't either as there will never be a one letter keyword. As for "tmp" it is a lot more descriptive than "var". Not all variables are holding temporary values but all are "variable" as their name already implies. Even i(=index) or n(=number of) bear a meaning in a mathematical context. I'm not all against short variable names (though I try to usually be more expressive) but their name should hint at their content or use. "var" doesn't hint at anything.
 I think Kris's point is that of the two choices 'var' and 'auto' the 
 latter is less likely to annoy someone by colliding with existing user 
 variables. The point is valid so long as the group of 'var' users is 
 bigger than the group of 'auto' users, even if both groups are small.
One should also consider future users of D since we haven't even reached 1.0 yet. Since no one else already uses "auto" for this purpose but a lot of languages use "var" I believe it to be the more intuitive option.
 C++ may be an abomination but it does have 'market' dominance. You have 
 to ask 'why'. You should learn from your 'enemies' ;)
But those reasons are mainly historical and may be summed up by "it's the least of all evils". This does not even hold true anymore. At least not when you look at language constructs and elegance. It's clearly "grown" not designed. Regards, Nils
Jul 25 2006
next sibling parent Don Clugston <dac nospam.com.au> writes:
Nils Hensel wrote:
 Regan Heath schrieb:
 I don't use "var" specifically but I have been known to use tmp, x, y, 
 i, j, p, s, n, .. for all my temporary and/or meaningless variables. 
 They typically have a short scope life and I can't see a problem with 
 this practice.
I don't either as there will never be a one letter keyword. As for "tmp" it is a lot more descriptive than "var". Not all variables are holding temporary values but all are "variable" as their name already implies. Even i(=index) or n(=number of) bear a meaning in a mathematical context. I'm not all against short variable names (though I try to usually be more expressive) but their name should hint at their content or use. "var" doesn't hint at anything.
It does. When I use it, 'var' is not an abbreviation of 'variable', it's an abbreviation of 'variant'.
 I think Kris's point is that of the two choices 'var' and 'auto' the 
 latter is less likely to annoy someone by colliding with existing user 
 variables. The point is valid so long as the group of 'var' users is 
 bigger than the group of 'auto' users, even if both groups are small.
One should also consider future users of D since we haven't even reached 1.0 yet. Since no one else already uses "auto" for this purpose but a lot of languages use "var" I believe it to be the more intuitive option.
 C++ may be an abomination but it does have 'market' dominance. You 
 have to ask 'why'. You should learn from your 'enemies' ;)
But those reasons are mainly historical and may be summed up by "it's the least of all evils". This does not even hold true anymore. At least not when you look at language constructs and elegance. It's clearly "grown" not designed. Regards, Nils
Jul 26 2006
prev sibling parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Nils Hensel wrote:

 I think Kris's point is that of the two choices 'var' and 'auto' the
 latter is less likely to annoy someone by colliding with existing user
 variables. The point is valid so long as the group of 'var' users is
 bigger than the group of 'auto' users, even if both groups are small.
One should also consider future users of D since we haven't even reached 1.0 yet. Since no one else already uses "auto" for this purpose but a lot of languages use "var" I believe it to be the more intuitive option.
Agreed ( it's also one letter shorter :-) ) -- AKhropov
Jul 27 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Nils Hensel wrote:
 kris schrieb:
 Don has a good point: changing to "var" would cause conflict with 
 existing variable-names.
I'm sorry but I don't believe there are many programmers out there actually using something as undescriptive as "var" as a regular identifier.
Maybe my first impression of the google search yourself -- the data is there. I also strongly believe that no one should. It's the
 implication of a maintenance nightmare.
 I don't intend to insult Don in any way but it's a horrible practice 
 IMNSHO that should not be preserved.
I don't understand. I can't see the difference between 'var' and 'x'. Do you also dislike use of 'i' as a counter variable in a for loop? (And if not, what is the difference?)
 So let's not focus on some odd minority but rather on the wide use of 
 "var" in the context of type inference and dynamic typing.
'var' is inappropriate in a statically typed language. Remember that 'static's are variables too. Note that 'auto' was one of the original C keywords, and was chosen without any constraint (no legacy code whatsoever, they could have chosen any name, including 'var'). Every variable was classed into either: static auto register
 Also I don't think that it's a good habit to be looking at how C++ does 
 something unless one is looking for a bad example. My main reason for 
 interest in D is because personally I'm fed up with C++ and consider it 
 an abomination and a major PITA.
Agreed, but the 'auto' thing ultimately comes from C, not C++.
Jul 25 2006
parent reply Nils Hensel <nils.hensel web.de> writes:
Don Clugston schrieb:
 Nils Hensel wrote:
 I'm sorry but I don't believe there are many programmers out there 
 actually using something as undescriptive as "var" as a regular 
 identifier. 
Maybe my first impression of the google search yourself -- the data is there.
I guess there are regular "var" users then but when I said "programmers" I was thinking of professionals used to the idiosyncrasies of medium to large software projects, where you're often faced with working on and maintaining someone elses code. I guess if the best description of a variable's intended meaning this somebody could come up with was "var" I'd be pretty pissed pretty soon.
 I don't intend to insult Don in any way but it's a horrible practice 
 IMNSHO that should not be preserved.
I don't understand. I can't see the difference between 'var' and 'x'. Do you also dislike use of 'i' as a counter variable in a for loop? (And if not, what is the difference?)
'x' and 'i' are often used in mathematical formulas and contexts so they already bear a meaning even if they look indescriptive. OTOH if someone uses 'i' as a string or a boolean variable I WOULD consider it a bad practice as well.
 'var' is inappropriate in a statically typed language. Remember that 
 'static's are variables too. Note that 'auto' was one of the original C 
 keywords, and was chosen without any constraint (no legacy code 
 whatsoever, they could have chosen any name, including 'var'). Every 
 variable was classed into either:
 
 static
 auto
 register
To be frank I don't get your point here. "static", "auto" and "register" are storage classes in these contexts (as they are originally in D). C has no concept of type inference. "auto" just means that the memory management for these variables is dealt with automatically because these variables exist on the stack. D just uses the fact that "auto" signifies the declaration of a variable which allows the compiler to identify the type automatically through the initializing value. The same holds true for "static" and "const". So actually D doesn't have an explicit type inference keyword yet.
 Also I don't think that it's a good habit to be looking at how C++ 
 does something unless one is looking for a bad example. My main reason 
 for interest in D is because personally I'm fed up with C++ and 
 consider it an abomination and a major PITA.
Agreed, but the 'auto' thing ultimately comes from C, not C++.
Yes, but not in the context of type inference. So the C "auto" is totally different from it's current D counterpart. Regards, Nils
Jul 27 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Nils Hensel wrote:
 Don Clugston schrieb:
 Nils Hensel wrote:
 I'm sorry but I don't believe there are many programmers out there 
 actually using something as undescriptive as "var" as a regular 
 identifier. 
Maybe my first impression of the google search yourself -- the data is there.
I guess there are regular "var" users then but when I said "programmers" I was thinking of professionals used to the idiosyncrasies of medium to large software projects, where you're often faced with working on and maintaining someone elses code. I guess if the best description of a variable's intended meaning this somebody could come up with was "var" I'd be pretty pissed pretty soon.
They're normally in trivial one-line functions.
 I don't intend to insult Don in any way but it's a horrible practice 
 IMNSHO that should not be preserved.
I don't understand. I can't see the difference between 'var' and 'x'. Do you also dislike use of 'i' as a counter variable in a for loop? (And if not, what is the difference?)
'x' and 'i' are often used in mathematical formulas and contexts so they already bear a meaning even if they look indescriptive. OTOH if someone uses 'i' as a string or a boolean variable I WOULD consider it a bad practice as well.
 'var' is inappropriate in a statically typed language. Remember that 
 'static's are variables too. Note that 'auto' was one of the original 
 C keywords, and was chosen without any constraint (no legacy code 
 whatsoever, they could have chosen any name, including 'var'). Every 
 variable was classed into either:

 static
 auto
 register
To be frank I don't get your point here. "static", "auto" and "register" are storage classes in these contexts (as they are originally in D). C has no concept of type inference. "auto" just means that the memory management for these variables is dealt with automatically because these variables exist on the stack.
 D just uses the fact that "auto" signifies the declaration of a variable 
  which allows the compiler to identify the type automatically  through 
 the initializing value. The same holds true for "static" and "const". So 
 actually D doesn't have an explicit type inference keyword yet.
No, the idea is *not* to have a type inference keyword, but instead only specify the storage class: static a = 7; const b = 7; auto c = 7; Now 'a' is a variable, just as much 'c' is. Are you proposing that you'd have to type: static var x = func(7); ? Surely not. 'const var' would be an abomination! The problem is, there's no storage class for local variables. In C/C++, there is, and it's called 'auto', but it's extremely rarely used in normal code. 'local' is perhaps the most natural name. I just don't like the idea that 'var' would mean "local non-static variable". "Variable" is a much broader category than "local variable". I hope that one day D also gets explicit thread-local variables. They would need a seperate storage class.
 Also I don't think that it's a good habit to be looking at how C++ 
 does something unless one is looking for a bad example. My main 
 reason for interest in D is because personally I'm fed up with C++ 
 and consider it an abomination and a major PITA.
Agreed, but the 'auto' thing ultimately comes from C, not C++.
Yes, but not in the context of type inference. So the C "auto" is totally different from it's current D counterpart.
No, it's not. It's a storage class in C++, *not* a type inference keyword. It's just that it's a storage class that in modern times is only used in the context of type inference. I think 'var' makes much more sense for dynamically typed languages. inference of constants?
Jul 27 2006
next sibling parent Nils Hensel <nils.hensel web.de> writes:
Don Clugston schrieb:
 No, the idea is *not* to have a type inference keyword, but instead only 
 specify the storage class:
 
 static a = 7;
 const b = 7;
 auto  c = 7;
 
 Now 'a' is a variable, just as much 'c' is.
 
 Are you proposing that you'd have to type:
 
 static var x =  func(7);
Actually yes. I find it to be clearer than just static x.
 ? Surely not. 'const var' would be an abomination!
I agree on that. "const x = 5;" is expressive enough in its own way. But I never said variables and constants should be treated the same.
 The problem is, there's no storage class for local variables. In C/C++, 
 there is, and it's called 'auto', but it's extremely rarely used in 
 normal code. 'local' is perhaps the most natural name.
Also agreed. I find "local" much better than "auto". But I'm afraid we have to carry this ugly legacy. The unexpressiveness of "auto" might be my whole problem with type inference as it is. Using storage classes for detection is a rather clever idea.
 I just don't like the idea that 'var' would mean "local non-static 
 variable". "Variable" is a much broader category than "local variable".
You have a point. But it is definitely the most often used type and what I believe most people think of when they hear "variable".
 I hope that one day D also gets explicit thread-local variables. They 
 would need a seperate storage class.
Sounds good to me.
 Agreed, but the 'auto' thing ultimately comes from C, not C++.
Yes, but not in the context of type inference. So the C "auto" is totally different from it's current D counterpart.
No, it's not. It's a storage class in C++, *not* a type inference keyword. It's just that it's a storage class that in modern times is only used in the context of type inference.
I think that's the same ugly legacy. I think D should drop things that are better expressed in a different way.
 I think 'var' makes much more sense for dynamically typed languages. 


 inference of constants?
Good question. But my guess is that for variables it's something like what you described above and that "const" does not get a "var". But it's just a guess. Regards, Nils
Jul 28 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:
 
 No, the idea is *not* to have a type inference keyword, but instead only 
 specify the storage class:
 
 static a = 7;
 const b = 7;
 auto  c = 7;
 
 Now 'a' is a variable, just as much 'c' is.
So long as the storage class is required, I'm all for it. This seems more consistent than what we have now.
 I hope that one day D also gets explicit thread-local variables. They 
 would need a seperate storage class.
I proposed this a while back and no one responded, so I went and added thread-local storage to Ares. But it would be much nicer to have this as a language feature.
 No, it's not. It's a storage class in C++, *not* a type inference 
 keyword. It's just that it's a storage class that in modern times is 
 only used in the context of type inference.
The things you learn. I don't think I've ever seen 'auto' used in a C or C++ program, though I've come across 'register' quite a bit. Sean
Jul 28 2006
prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 25 Jul 2006 10:17:13 -0700, kris <foo bar.com> wrote:
 Don has a good point: changing to "var" would cause conflict with  
 existing variable-names.

 Chad et. al. also have a good point about the conflict regarding static  
 opCall() (via the lack of a "new" keyword). I suspect many people find  
 the use of "new" to be indicative of allocation, and breaking this  
 consistency may have a detrimental effect? Further, it was noted that a  
 missing "new" can only be used at the instantiation site -- not at the  
 class decl -- thus, D would be losing an existing feature.

 I suspect you could count the current number of raii-class uses on a few  
 hands, whereas the use of "auto" for implied-type is pretty darned  
 popular -- and rightly so, since it's really very, very useful. Changing  
 the raii style to use a different keyword, whilst retaining implied-type  
 "auto" would be an almost imperceptible change?

 Thus, it would appear to make sense to retain "auto" for implied-type,  
 and introduce something *else* for automatic cleanup at end-of-scope  
 (and also as a class attribute). how about reusing the "scope" keyword?

 void main()
 {
    auto i = 10;
    auto foo = new Foo;
    auto scope bar = new Bar;
    auto scope wumpus = new Wumpus;
 }

 class Foo {}

 class Bar {}

 scope class Wumpus {}
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 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
Jul 25 2006
next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
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. 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. Scope is not allocation. For instance, if the function is inlined then something allocated on the stack should live longer than the scope of the function. The only exceptions I can think of are if the compiler forbids inlining of such functions (possibly inefficient) or there is a scope guarantee, in which case you want scope AND stack alloc. Or maybe I just don't understand inlining (hope not!).
 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. 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. As I said in the 1.0 thread, A a = A(); looks to me like anything but a scoped instanciation; I'd rather have a keyword (like scope) to indicate what it is in an explicit way. 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()'. 
I do like using the scope keyword for this btw. It seems quite consistant with D's meaning of 'scope'.
Jul 25 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 25 Jul 2006 23:28:24 -0400, Chad J  
<gamerChad _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
Jul 25 2006
next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Wed, 26 Jul 2006 00:13:53 -0400, Regan Heath <regan netwin.co.nz> wrote:
 1. 'new' implies heap allocation
Except when it doesn't. I'm talking about overloaded 'new' If Object`s were given 2 default new() implmentations, one that does the current allocation, and another that allows you to specify a buffer (also so that every Joe who wants this doesn't have to derive from the class to provide it). When RAII is involved, it can choose which version of new() to use (implementaion defined), using stack or not.
Jul 25 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 26 Jul 2006 00:23:41 -0400, Chris Miller <chris dprogramming.com>  
wrote:
 On Wed, 26 Jul 2006 00:13:53 -0400, Regan Heath <regan netwin.co.nz>  
 wrote:
 1. 'new' implies heap allocation
Except when it doesn't. I'm talking about overloaded 'new' If Object`s were given 2 default new() implmentations, one that does the current allocation, and another that allows you to specify a buffer (also so that every Joe who wants this doesn't have to derive from the class to provide it). When RAII is involved, it can choose which version of new() to use (implementaion defined), using stack or not.
You're describing 'placement' new, yes? http://www.informit.com/guides/content.asp?g=cplusplus&seqNum=160&rl=1 I dont think D has placement new, at least not a syntax for it like C++. I could be wrong. You're right in that if D were to get placement new using the C++ syntax then the suggested RAII syntax (removing 'new') would make it impossible to declare an RAII class using placement new. But, it appears that placement new in D is done with a custom allocator and not a special syntax? http://www.digitalmars.com/d/memory.html#newdelete You coud write a custom allocator which would calculate offsets into pre-allocated memory returning that address for each allocation. Essentially placement new without the special syntax. Has this topic come up before? What was Walters comment on it? I don't recall a discussion on it, I did a quick search and didn't turn up anything specific. I wonder, does placement new in D have the same restrictions as in C++? i.e. cannot use stack memory, requires explicit 'delete'. I wonder what constraints the RAII implementation in D puts on how objects are allocated. It's possible they can't be allocated on the stack .. I seem to recall Walter saying he'd like to go there, eventually, but I might be imagining things. Regan
Jul 25 2006
parent reply "Chris Miller" <chris dprogramming.com> writes:
On Wed, 26 Jul 2006 01:23:53 -0400, Regan Heath <regan netwin.co.nz> wro=
te:

 On Wed, 26 Jul 2006 00:23:41 -0400, Chris Miller  =
 <chris dprogramming.com> wrote:
 On Wed, 26 Jul 2006 00:13:53 -0400, Regan Heath <regan netwin.co.nz> =
=
 wrote:
 1. 'new' implies heap allocation
Except when it doesn't. I'm talking about overloaded 'new' If Object`s were given 2 default new() implmentations, one that does =
=
 the current allocation, and another that allows you to specify a buff=
er =
 (also so that every Joe who wants this doesn't have to derive from th=
e =
 class to provide it). When RAII is involved, it can choose which  =
 version of new() to use (implementaion defined), using stack or not.
You're describing 'placement' new, yes? http://www.informit.com/guides/content.asp?g=3Dcplusplus&seqNum=3D160&=
rl=3D1
 I dont think D has placement new, at least not a syntax for it like C+=
+. =
 I could be wrong.

 You're right in that if D were to get placement new using the C++ synt=
ax =
 then the suggested RAII syntax (removing 'new') would make it impossib=
le =
 to declare an RAII class using placement new. But, it appears that  =
 placement new in D is done with a custom allocator and not a special  =
 syntax?

 http://www.digitalmars.com/d/memory.html#newdelete
I hadn't thought of 'placement' new but this page is what I was referrin= g = to. Scroll down to "Allocating Class Instances On The Stack" to see what= I = meant. Different uses of 'new' (RAII/regular) could call different new()= s, = which doesn't imply heap.
Jul 27 2006
parent Sean Kelly <sean f4.ca> writes:
Chris Miller wrote:
 On Wed, 26 Jul 2006 01:23:53 -0400, Regan Heath <regan netwin.co.nz> wrote:
 http://www.digitalmars.com/d/memory.html#newdelete
I hadn't thought of 'placement' new but this page is what I was referring to. Scroll down to "Allocating Class Instances On The Stack" to see what I meant. Different uses of 'new' (RAII/regular) could call different new()s, which doesn't imply heap.
This is placement new--the parameter to new specifies the location where the object will be constructed. Sean
Jul 27 2006
prev sibling next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Regan Heath wrote:
 On Tue, 25 Jul 2006 23:28:24 -0400, Chad J  
 <gamerChad _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?
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?
Jul 26 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
 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.
I've already said.. I think it's intuitive because it 'looks' like a class declared on the stack, as in C++ and like those it will be destroyed at the end of scope. Your counter argument is that not everyone is a C++ programmer, correct? In which case, read on..
 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?
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 come from a C background. I have done a little C++, a little Java and
 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.
The absence of 'new' gives us the required information. You are required to know what the absense of 'new' _means_ just like you are required to know what keyword X means in any given context. In short, some knowledge of programming in D is required to program in D. To expand on why I think it's intuitive let look at 2 scenarios, first the C++ programmer trying D. Likely their first program involving classes will look like this: class A { int a; } void main() { A a = A(); writefln(a.a); } currently, this crashes with an access violation. Add the new RAII syntax and not only does it not crash, but it behaves just like a C++ program would with A being destroyed at the end of scope. class A { int a; } void main() { A a = new A(); writefln(a.a); } No crash, and the behaviour they expect. Then imagine the same programmers looking at each others code, the C++ programmer will understand 'new' to indicate heap allocation and the 'new' means, he'll reply that the class is destroyed at the end of scope. He might also say it's stack allocated, but that's fine, both of them have something to learn, and it has no effect on the way the program behaves. Simple, intuitive and elegant no matter what your background. Of course, 'new' means. Both have to learn that D might not stack allocate the RAII class instance. If we use a 'scope' keyword then both sets of programmers have some learning to do. It's not much worse, but this makes it my 2nd choice.
 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.
The C++ programmer will already know what it does. The Java/C++ programmer will search for 'new' (because it's absent). In either case they'll find the docs on RAII at the same time as they find the docs on 'new'.
 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.
I've assumed programmers from 2 types of background above, I still think removing 'new' is better than adding 'scope'.
  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.
I'm assuming this defintion: http://en.wikipedia.org/wiki/Information_hiding I'm not sure I follow your logic, did you mean "encapsulation" instead? If you did mean "information hiding" then it seems to me that using opCall is a design decision, just as using a method called "Bob" would be. The advantage to using "Bob" is that you can define an 'stable' interface eg. interface MyImplementation { int Bob(int x); } and in that way protect your code against changes in implementation. In short, this is a better "information hiding" solution than using static opCall.
 Why not a free function? - I'm assuming you mean a normal function  
 declared at module scope.
Yes.
 It allows you to have multiple functions with access to the same  
 non-static variables (member variables).
What does? _static_ opCall does *not* have access to non-static variables, it can only access static variables. Static methods and variables are very similar to module level variables. The difference being how to access them (class name prefix) and where they are declared (inside the class instead of at module level). You can replace static methods and variables with module level ones quite easily.
 I suppose this is usually accomplished with nested functions, or OOP  
 that can't do implementation hiding.
I'm obviously not following your point here.. can you elaborate, perhaps another example?
 Doing it this way allows me to avoid forward referencing issues
What forward referencing issues does the code above have?
 and also gives me more options about how my code behaves.
What options? example?
 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.
So far: - I'm not seeing the forward reference issue(s) - It seems like a worse way to implement information hiding (than an interface and method).
 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.
I *like* non-static opCall, I can see benefits to that. But, so far, static opCall seems to be fairly useless to me.
 *sigh* those were long winded answers, sorry about that.
No worries. Long winded tends to imply more information and that's not a bad thing.
 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?
I'm trying, by learning when, where and why you use it. I can't think of a place where _I_ would use it (which is why I think it's not useful). It's only a 'hack' when used with a struct to emulate a constructor. Strangely that 'hack' is the only vaguely good use I've seen for a *static* opCall. Regan
Jul 26 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Regan Heath wrote:
 
...
 I've already said.. I think it's intuitive because it 'looks' like a 
 class  declared on the stack, as in C++ and like those it will be 
 destroyed at  the end of scope. Your counter argument is that not 
 everyone is a  C++ programmer, correct? In which case, read on..
 
...
 
 I come from a C background. I have done a little C++, a little Java and  

 
 
 The absence of 'new' gives us the required information. You are 
 required  to know what the absense of 'new' _means_ just like you are 
 required to  know what keyword X means in any given context. In short, 
 some knowledge  of programming in D is required to program in D.
I agree, the point is to make it easier to obtain that knowledge while learning.
 
 To expand on why I think it's intuitive let look at 2 scenarios, first 
 the  C++ programmer trying D. Likely their first program involving 
 classes will  look like this:
 
 class A {
   int a;
 }
 
 void main() {
   A a = A();
   writefln(a.a);
 }
 
 currently, this crashes with an access violation. 
Actually, it doesn't compile. main.d(6): function expected before (), not A of type main.A main.d(6): cannot implicitly convert expression ((A)()) of type int to main.A Maybe not the best error messages for this case, but better than an access violation.
 Add the new RAII 
 syntax  and not only does it not crash, but it behaves just like a C++ 
 program  would with A being destroyed at the end of scope.
I hear that such syntax, in C++, means that 'A' will be stack allocated, which AFAIK does not imply RAII. One example I can think of that would break RAII is if the function gets inlined, then the stack allocated object may not be deleted until some point outside of the scope's end. It will /probably/ be deleted at the end of the function that the enclosing function was inlined into. I could be wrong about that though. Also, does that C++ syntax allow class references to leak into code that is executed after the class is deleted?
 

 
 class A {
   int a;
 }
 
 void main() {
   A a = new A();
   writefln(a.a);
 }
 
 No crash, and the behaviour they expect.
 
 Then imagine the same programmers looking at each others code, the  C++ 
 programmer will understand 'new' to indicate heap allocation and the  

 of  'new' means, he'll reply that the class is destroyed at the end of 
 scope.  He might also say it's stack allocated, but that's fine, both of 
 them have  something to learn, and it has no effect on the way the 
 program behaves.
That learning process would be nice, but it assumes an extra programmer being around. As I learn D, I am alone. Either I go to the spec or I ask on the newsgroup. I'm not sure how many others are in the same situation. I've explained below why I still don't think it's very obvious, which means more potential newsgroup asking. That doesn't bug me too much though.
 
 Simple, intuitive and elegant no matter what your background. Of 

 absense of  'new' means. Both have to learn that D might not stack 
 allocate the RAII  class instance.
 
 If we use a 'scope' keyword then both sets of programmers have some  
 learning to do. It's not much worse, but this makes it my 2nd choice.
 
"Both have to learn that D might not stack allocate the RAII class instance." "If we use a 'scope' keyword then both sets of programmers have some learning to do." If they both have learning to do anyways, why not just have them learn 'scope'? I suppose it wouldn't be too bad otherwise, except for one problem: The unfortunate C++ programmer's program worked as expected. I say problem and unfortunate, because they may just assume that D behaves like C++ in all of the corner cases, and if I'm correct about the RAII vs stack alloc above, it may not.
 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.
The C++ programmer will already know what it does. The Java/C++ programmer will search for 'new' (because it's absent). In either case they'll find the docs on RAII at the same time as they find the docs on 'new'.
Searching for 'new' is a good idea. What if they don't think of that? The only reason I would associate the absence of 'new' with allocation is because of the talk from C++ programmers on this newsgroup. Otherwise it's some kind of wacky cool feature of D that they have not read about yet (as it is now!). This is why I prefer 'scope' - it would make scope, unambiguously, THE keyword to search for to find out what's going on.
 
 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.
I've assumed programmers from 2 types of background above, I still think removing 'new' is better than adding 'scope'.
That's fine as long as you clear up the two things: - What tells a non-C++ coder to look up 'new'? (besides another coder) - The possible assumption by a C++ coder that RAII syntax means stack allocation. (and subsequent whammy when they hit a pointy corner case) Proving that there are no corner cases in 'stack allocation implies RAII' or me being wrong about that meaning in C++ should clear up that second one.
   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.
I'm assuming this defintion: http://en.wikipedia.org/wiki/Information_hiding I'm not sure I follow your logic, did you mean "encapsulation" instead? If you did mean "information hiding" then it seems to me that using opCall is a design decision, just as using a method called "Bob" would be. The advantage to using "Bob" is that you can define an 'stable' interface eg. interface MyImplementation { int Bob(int x); } and in that way protect your code against changes in implementation. In short, this is a better "information hiding" solution than using static opCall.
 Why not a free function? - I'm assuming you mean a normal function  
 declared at module scope.
Yes.
 It allows you to have multiple functions with access to the same  
 non-static variables (member variables).
What does? _static_ opCall does *not* have access to non-static variables, it can only access static variables. Static methods and variables are very similar to module level variables. The difference being how to access them (class name prefix) and where they are declared (inside the class instead of at module level). You can replace static methods and variables with module level ones quite easily.
 I suppose this is usually accomplished with nested functions, or OOP  
 that can't do implementation hiding.
I'm obviously not following your point here.. can you elaborate, perhaps another example?
 Doing it this way allows me to avoid forward referencing issues
What forward referencing issues does the code above have?
 and also gives me more options about how my code behaves.
What options? example?
 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.
So far: - I'm not seeing the forward reference issue(s) - It seems like a worse way to implement information hiding (than an interface and method).
 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.
I *like* non-static opCall, I can see benefits to that. But, so far, static opCall seems to be fairly useless to me.
 *sigh* those were long winded answers, sorry about that.
No worries. Long winded tends to imply more information and that's not a bad thing.
 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?
I'm trying, by learning when, where and why you use it. I can't think of a place where _I_ would use it (which is why I think it's not useful). It's only a 'hack' when used with a struct to emulate a constructor. Strangely that 'hack' is the only vaguely good use I've seen for a *static* opCall. Regan
OK I think I have not explained my example very well. First I'll simplify my original example and try harder to explain. I've added comments this time. Here it is: import std.stdio; // class used as a function class f { int result; int tempVar1; // this is your non-static variable static int opCall( int x ) { // what do you know, not so 'static' after all! f instance = new f(x); int result = instance.result; // cleanup delete instance; return result; } this( int x ) { // If this were a function with nested functions, // then the main execution would occur here. result = x + internalFunc(); } // this is a non-static function int internalFunc() { return 314; } } void main() { int x = 42; x = f(x); writefln(x); } Now I'll rewrite it into a free function: import std.stdio; int f( int x ) { // Error! internalFunc is not defined. return x + internalFunc(); // oh but here it is... nested functions don't allow this int internalFunc() { return 314; } } void main() { int x = 42; x = f(x); writefln(x); } In a trivial case like this all you have to do is move the nested function internalFunc to the top. In other cases though, where you want to be able to places the functions where they intuitively belong, this becomes annoying. This is that forward referencing issue I was talking about. Also, if 'f' were derived from another class, then the code executed in f's constructor would have access to the super class's members. That's more to do with OOP, but it's all hidden behind a static opCall. I suppose you could use a module function to construct and delete a private class that gets used for it's own scope and inheritance. I worry that I am missing some detail that stopped me from just doing that before. Sean, perhaps you could share some of your uses for static opCall since I'm doing such a bad job at this? Only slightly related - I wonder if D's 'new' even implies heap allocation as it is. That might just be a dmd thing, but I am looking in the spec at Classes -> ctors/dtors, and it doesn't say where they get allocated. Maybe someone who is good at searching the spec can find if it says where classes get allocated? My thought, as xs0 has mentioned as well, is that 'new' could be defined independant of those implementation details. For example, just say that 'new' will allocate a class instance, and that the instance will be cleaned up only after there are no more references to that class. The only exception being explicit deletion. Since RAII gaurantees, AFAIK, that there are no references leaked into code that gets executed after the scope is exited, then stack allocation would work here. I'm finding it hard to imagine code that would require an object to be in the heap's address range or in the stack's address range. xs0 says there are other cases in which a class can be allocated on the stack without breaking the gaurantees of no premature deletion, and I wonder what they are.
Jul 28 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 28 Jul 2006 04:44:44 -0400, Chad J  
<gamerChad _spamIsBad_gmail.com> wrote:
 Regan Heath wrote:

 ...
 I've already said.. I think it's intuitive because it 'looks' like a  
 class  declared on the stack, as in C++ and like those it will be  
 destroyed at  the end of scope. Your counter argument is that not  
 everyone is a  C++ programmer, correct? In which case, read on..
...
  I come from a C background. I have done a little C++, a little Java  

   The absence of 'new' gives us the required information. You are  
 required  to know what the absense of 'new' _means_ just like you are  
 required to  know what keyword X means in any given context. In short,  
 some knowledge  of programming in D is required to program in D.
I agree, the point is to make it easier to obtain that knowledge while learning.
  To expand on why I think it's intuitive let look at 2 scenarios, first  
 the  C++ programmer trying D. Likely their first program involving  
 classes will  look like this:
  class A {
   int a;
 }
  void main() {
   A a = A();
   writefln(a.a);
 }
  currently, this crashes with an access violation.
Actually, it doesn't compile. main.d(6): function expected before (), not A of type main.A main.d(6): cannot implicitly convert expression ((A)()) of type int to main.A Maybe not the best error messages for this case, but better than an access violation.
Err.. oops.. my example was in fact assuming the new "omit 'new'" syntax was added, then I went and confused it with: A a; writefln(a.a); which is actually what a C++ programmer would write to allocate a class on the stack and have it destroyed at end of scope. The syntax: A a; writefln(a.a); will crash, the new syntax isn't invloved at all, sorry.
 Add the new RAII syntax  and not only does it not crash, but it behaves  
 just like a C++ program  would with A being destroyed at the end of  
 scope.
I hear that such syntax, in C++, means that 'A' will be stack allocated, which AFAIK does not imply RAII.
No, but the resulting behaviour is almost identical. In C++ the syntax: A a; causes 'a' to be allocated on the stack and the destructor called at end of scope. Apart from being allocated on the stack (which Walter indicates in the docs is something he plans to implement at a later date for 'auto') it's identical to the behaviour of D's 'auto'. http://www.digitalmars.com/d/memory.html#stackclass "To have a class allocated on the stack that has a destructor, this is the same as a declaration with the auto attribute. Although the current implementation does not put such objects on the stack, future ones can."
 One example I can think of that would
 break RAII is if the function gets inlined, then the stack allocated
 object may not be deleted until some point outside of the scope's end.
 It will /probably/ be deleted at the end of the function that the
 enclosing function was inlined into.  I could be wrong about that though.
I'm not sure what happens when something is inlined either.
 Also, does that C++ syntax allow class references to leak into code that
 is executed after the class is deleted?
I would expect not. They should be destroyed when the scope ends and the stack space is released.

 be:
  class A {
   int a;
 }
  void main() {
   A a = new A();
   writefln(a.a);
 }
  No crash, and the behaviour they expect.
  Then imagine the same programmers looking at each others code, the   
 C++ programmer will understand 'new' to indicate heap allocation and  

 absense of  'new' means, he'll reply that the class is destroyed at the  
 end of scope.  He might also say it's stack allocated, but that's fine,  
 both of them have  something to learn, and it has no effect on the way  
 the program behaves.
That learning process would be nice, but it assumes an extra programmer being around. As I learn D, I am alone. Either I go to the spec or I ask on the newsgroup. I'm not sure how many others are in the same situation.
In the case where you're not looking at someone elses code you'll never write: A a = A(); so you will not learn about it until you go looking for RAII. There you'll find the syntax, learn it, and carry on. It's no harder to learn than a keyword 'local'.
 I've explained below why I still don't think it's very obvious, which
 means more potential newsgroup asking.  That doesn't bug me too much
 though.
I'm not especially bothered which syntax is chosen, I just like discussing stuff.
  Simple, intuitive and elegant no matter what your background. Of  

 absense of  'new' means. Both have to learn that D might not stack  
 allocate the RAII  class instance.
  If we use a 'scope' keyword then both sets of programmers have some   
 learning to do. It's not much worse, but this makes it my 2nd choice.
"Both have to learn that D might not stack allocate the RAII class instance." "If we use a 'scope' keyword then both sets of programmers have some learning to do." 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'?
 I suppose it wouldn't be too bad otherwise, except for one problem:
 The unfortunate C++ programmer's program worked as expected.
Actually, my example was wrong and it doesn't. This poor guy still gets an access violation. Perhaps the new 'auto' syntax should just be: A a; then, my previous example and point would be valid.
 I say problem and unfortunate, because they may just assume that D
 behaves like C++ in all of the corner cases, and if I'm correct about
 the RAII vs stack alloc above, it may not.
One of the things Walter tends to do (which bothers some D users) is to emulate C/C++ where appropriate. This makes porting C/C++ to D easier because there aren't corner cases where it does something subtley different. Of course I may be wrong, there may be a corner case, but I believe Walter intentionally tries to reduce these. 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.
 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.
The C++ programmer will already know what it does. The Java/C++ programmer will search for 'new' (because it's absent). In either case they'll find the docs on RAII at the same time as they find the docs on 'new'.
Searching for 'new' is a good idea. What if they don't think of that?
Then they'll look for the section on variables, or class references, or declaring variables in function, or .. It shouldn't be all that hard to find, assuming half decent documentation.
 The only reason I would associate the absence of 'new' with allocation
 is because of the talk from C++ programmers on this newsgroup.
 Otherwise it's some kind of wacky cool feature of D that they have not
 read about yet (as it is now!).  This is why I prefer 'scope' - it would
 make scope, unambiguously, THE keyword to search for to find out what's
 going on.
Have you tried searching for an existing D keyword in the docs? First you have to decide which section to go to; is it a declaration, is it a type, is it a property, is it .. Sure it could be made easier with different documentation but that's all this boils down to, ensuring the information is in a logical place, if that's the case it makes no difference whether your searching for a specific keyword or 'RAII' or 'new' or 'class' etc. In an ideal world whatever you search for should find the results you need.
 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.
I've assumed programmers from 2 types of background above, I still think removing 'new' is better than adding 'scope'.
That's fine as long as you clear up the two things: - What tells a non-C++ coder to look up 'new'? (besides another coder)
See above. This is a documentation issue.
 - The possible assumption by a C++ coder that RAII syntax means stack
 allocation.  (and subsequent whammy when they hit a pointy corner case)

 Proving that there are no corner cases in 'stack allocation implies
 RAII' or me being wrong about that meaning in C++ should clear up that
 second one.
See above. I believe the behaviour is almost identical (and may become identical in the future). I believe Walter intentionally avoids corner cases WRT C++ behavior. That's the best I can do.. if I knew of a corner case I'd let you know ;)
   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.
I'm assuming this defintion: http://en.wikipedia.org/wiki/Information_hiding I'm not sure I follow your logic, did you mean "encapsulation" instead? If you did mean "information hiding" then it seems to me that using opCall is a design decision, just as using a method called "Bob" would be. The advantage to using "Bob" is that you can define an 'stable' interface eg. interface MyImplementation { int Bob(int x); } and in that way protect your code against changes in implementation. In short, this is a better "information hiding" solution than using static opCall.
 Why not a free function? - I'm assuming you mean a normal function   
 declared at module scope.
Yes.
 It allows you to have multiple functions with access to the same   
 non-static variables (member variables).
What does? _static_ opCall does *not* have access to non-static variables, it can only access static variables. Static methods and variables are very similar to module level variables. The difference being how to access them (class name prefix) and where they are declared (inside the class instead of at module level). You can replace static methods and variables with module level ones quite easily.
 I suppose this is usually accomplished with nested functions, or OOP   
 that can't do implementation hiding.
I'm obviously not following your point here.. can you elaborate, perhaps another example?
 Doing it this way allows me to avoid forward referencing issues
What forward referencing issues does the code above have?
 and also gives me more options about how my code behaves.
What options? example?
 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.
So far: - I'm not seeing the forward reference issue(s) - It seems like a worse way to implement information hiding (than an interface and method).
 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.
I *like* non-static opCall, I can see benefits to that. But, so far, static opCall seems to be fairly useless to me.
 *sigh* those were long winded answers, sorry about that.
No worries. Long winded tends to imply more information and that's not a bad thing.
 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?
I'm trying, by learning when, where and why you use it. I can't think of a place where _I_ would use it (which is why I think it's not useful). It's only a 'hack' when used with a struct to emulate a constructor. Strangely that 'hack' is the only vaguely good use I've seen for a *static* opCall. Regan
OK I think I have not explained my example very well. First I'll simplify my original example and try harder to explain. I've added comments this time. Here it is: import std.stdio; // class used as a function class f { int result; int tempVar1; // this is your non-static variable static int opCall( int x ) { // what do you know, not so 'static' after all! f instance = new f(x); int result = instance.result; // cleanup delete instance; return result; } this( int x ) { // If this were a function with nested functions, // then the main execution would occur here. result = x + internalFunc(); } // this is a non-static function int internalFunc() { return 314; } } void main() { int x = 42; x = f(x); writefln(x); } Now I'll rewrite it into a free function: import std.stdio; int f( int x ) { // Error! internalFunc is not defined. return x + internalFunc(); // oh but here it is... nested functions don't allow this int internalFunc() { return 314; } }
Err.. you've re-written your constructor as a free function? not the static opCall. Why? I would have expected this free function: int free_function( int x ) { // what do you know, not so 'static' after all! f instance = new f(x); int result = instance.result; // cleanup delete instance; return result; } void main() { int x = 42; x = free_function(x); writefln(x); } I've gotta go.. so, I'll just post what I've said so far and see what you respond with.. I may reply again to the stuff below.. :) Regan
 In a trivial case like this all you have to do is move the nested
 function internalFunc to the top.  In other cases though, where you want
 to be able to places the functions where they intuitively belong, this
 becomes annoying.  This is that forward referencing issue I was talking
 about.

 Also, if 'f' were derived from another class, then the code executed in  
 f's constructor would have access to the super class's members.  That's  
 more to do with OOP, but it's all hidden behind a static opCall.

 I suppose you could use a module function to construct and delete a  
 private class that gets used for it's own scope and inheritance.  I  
 worry that I am missing some detail that stopped me from just doing that  
 before.

 Sean, perhaps you could share some of your uses for static opCall since  
 I'm doing such a bad job at this?


 Only slightly related - I wonder if D's 'new' even implies heap  
 allocation as it is.  That might just be a dmd thing, but I am looking  
 in the spec at Classes -> ctors/dtors, and it doesn't say where they get  
 allocated.  Maybe someone who is good at searching the spec can find if  
 it says where classes get allocated?
 My thought, as xs0 has mentioned as well, is that 'new' could be defined  
 independant of those implementation details.  For example, just say that  
 'new' will allocate a class instance, and that the instance will be  
 cleaned up only after there are no more references to that class.  The  
 only exception being explicit deletion.  Since RAII gaurantees, AFAIK,  
 that there are no references leaked into code that gets executed after  
 the scope is exited, then stack allocation would work here.  I'm finding  
 it hard to imagine code that would require an object to be in the heap's  
 address range or in the stack's address range.  xs0 says there are other  
 cases in which a class can be allocated on the stack without breaking  
 the gaurantees of no premature deletion, and I wonder what they are.
Jul 28 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Regan Heath wrote:
 On Fri, 28 Jul 2006 04:44:44 -0400, Chad J  
 <gamerChad _spamIsBad_gmail.com> wrote:
 
 Regan Heath wrote:

  To expand on why I think it's intuitive let look at 2 scenarios, 
 first  the  C++ programmer trying D. Likely their first program 
 involving  classes will  look like this:
  class A {
   int a;
 }
  void main() {
   A a = A();
   writefln(a.a);
 }
  currently, this crashes with an access violation.
Actually, it doesn't compile. main.d(6): function expected before (), not A of type main.A main.d(6): cannot implicitly convert expression ((A)()) of type int to main.A Maybe not the best error messages for this case, but better than an access violation.
Err.. oops.. my example was in fact assuming the new "omit 'new'" syntax was added, then I went and confused it with: A a; writefln(a.a); which is actually what a C++ programmer would write to allocate a class on the stack and have it destroyed at end of scope. The syntax: A a; writefln(a.a); will crash, the new syntax isn't invloved at all, sorry.
 Add the new RAII syntax  and not only does it not crash, but it 
 behaves  just like a C++ program  would with A being destroyed at the 
 end of  scope.
I hear that such syntax, in C++, means that 'A' will be stack allocated, which AFAIK does not imply RAII.
No, but the resulting behaviour is almost identical. In C++ the syntax: A a; causes 'a' to be allocated on the stack and the destructor called at end of scope. Apart from being allocated on the stack (which Walter indicates in the docs is something he plans to implement at a later date for 'auto') it's identical to the behaviour of D's 'auto'. http://www.digitalmars.com/d/memory.html#stackclass "To have a class allocated on the stack that has a destructor, this is the same as a declaration with the auto attribute. Although the current implementation does not put such objects on the stack, future ones can."
 One example I can think of that would
 break RAII is if the function gets inlined, then the stack allocated
 object may not be deleted until some point outside of the scope's end.
 It will /probably/ be deleted at the end of the function that the
 enclosing function was inlined into.  I could be wrong about that though.
I'm not sure what happens when something is inlined either.
 Also, does that C++ syntax allow class references to leak into code that
 is executed after the class is deleted?
I would expect not. They should be destroyed when the scope ends and the stack space is released.

 will  be:
  class A {
   int a;
 }
  void main() {
   A a = new A();
   writefln(a.a);
 }
  No crash, and the behaviour they expect.
  Then imagine the same programmers looking at each others code, the   
 C++ programmer will understand 'new' to indicate heap allocation and  

 absense of  'new' means, he'll reply that the class is destroyed at 
 the  end of scope.  He might also say it's stack allocated, but 
 that's fine,  both of them have  something to learn, and it has no 
 effect on the way  the program behaves.
That learning process would be nice, but it assumes an extra programmer being around. As I learn D, I am alone. Either I go to the spec or I ask on the newsgroup. I'm not sure how many others are in the same situation.
In the case where you're not looking at someone elses code you'll never write: A a = A(); so you will not learn about it until you go looking for RAII. There you'll find the syntax, learn it, and carry on. It's no harder to learn than a keyword 'local'.
When reading other people's code, I find that most often I don't know or work with the other people. I'd have to contact them to learn from them. The easier option, for me, and probably them too, is to do a search in the spec, even if that is a bit difficult as-is.
 I've explained below why I still don't think it's very obvious, which
 means more potential newsgroup asking.  That doesn't bug me too much
 though.
I'm not especially bothered which syntax is chosen, I just like discussing stuff.
  Simple, intuitive and elegant no matter what your background. Of  

 absense of  'new' means. Both have to learn that D might not stack  
 allocate the RAII  class instance.
  If we use a 'scope' keyword then both sets of programmers have 
 some   learning to do. It's not much worse, but this makes it my 2nd 
 choice.
"Both have to learn that D might not stack allocate the RAII class instance." "If we use a 'scope' keyword then both sets of programmers have some learning to do." 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. You still have a point wrt similarity, though I dislike subtly different behaviours as it can lead to bad assumptions.
 I suppose it wouldn't be too bad otherwise, except for one problem:
 The unfortunate C++ programmer's program worked as expected.
Actually, my example was wrong and it doesn't. This poor guy still gets an access violation. Perhaps the new 'auto' syntax should just be: A a; then, my previous example and point would be valid.
 I say problem and unfortunate, because they may just assume that D
 behaves like C++ in all of the corner cases, and if I'm correct about
 the RAII vs stack alloc above, it may not.
One of the things Walter tends to do (which bothers some D users) is to emulate C/C++ where appropriate. This makes porting C/C++ to D easier because there aren't corner cases where it does something subtley different. Of course I may be wrong, there may be a corner case, but I believe Walter intentionally tries to reduce these. 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? A a; Currently that is the syntax for declaring a variable. It will break any code that relies on 'a' being initialized to null. 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.
 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.
The C++ programmer will already know what it does. The Java/C++ programmer will search for 'new' (because it's absent). In either case they'll find the docs on RAII at the same time as they find the docs on 'new'.
Searching for 'new' is a good idea. What if they don't think of that?
Then they'll look for the section on variables, or class references, or declaring variables in function, or .. It shouldn't be all that hard to find, assuming half decent documentation.
 The only reason I would associate the absence of 'new' with allocation
 is because of the talk from C++ programmers on this newsgroup.
 Otherwise it's some kind of wacky cool feature of D that they have not
 read about yet (as it is now!).  This is why I prefer 'scope' - it would
 make scope, unambiguously, THE keyword to search for to find out what's
 going on.
Have you tried searching for an existing D keyword in the docs? First you have to decide which section to go to; is it a declaration, is it a type, is it a property, is it .. Sure it could be made easier with different documentation but that's all this boils down to, ensuring the information is in a logical place, if that's the case it makes no difference whether your searching for a specific keyword or 'RAII' or 'new' or 'class' etc. In an ideal world whatever you search for should find the results you need.
Yeah. I find the current situation wrt searching the D spec pretty clumsy. It would really help to be able to search the spec, and just the spec, and not the forums or anything else at the same time. I think once that is handled, then using keywords searches will narrow things down to a very small number of results that someone could read through. Having to figure out what section something is in is good in some cases, but in others is a real drag IMO :(
 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.
I've assumed programmers from 2 types of background above, I still think removing 'new' is better than adding 'scope'.
That's fine as long as you clear up the two things: - What tells a non-C++ coder to look up 'new'? (besides another coder)
See above. This is a documentation issue.
 - The possible assumption by a C++ coder that RAII syntax means stack
 allocation.  (and subsequent whammy when they hit a pointy corner case)

 Proving that there are no corner cases in 'stack allocation implies
 RAII' or me being wrong about that meaning in C++ should clear up that
 second one.
See above. I believe the behaviour is almost identical (and may become identical in the future). I believe Walter intentionally avoids corner cases WRT C++ behavior. That's the best I can do.. if I knew of a corner case I'd let you know ;)
 OK I think I have not explained my example very well.
 First I'll simplify my original example and try harder to explain.  I've
 added comments this time.
 Here it is:

 import std.stdio;

 // class used as a function
 class f
 {
      int result;
      int tempVar1; // this is your non-static variable

      static int opCall( int x )
      {
          // what do you know, not so 'static' after all!
          f instance = new f(x);
          int result = instance.result;

          // cleanup
          delete instance;
          return result;
      }

      this( int x )
      {
          // If this were a function with nested functions,
          //   then the main execution would occur here.
          result = x + internalFunc();
      }

      // this is a non-static function
      int internalFunc()
      {
          return 314;
      }
 }

 void main()
 {
      int x = 42;
      x = f(x);
      writefln(x);
 }

 Now I'll rewrite it into a free function:

 import std.stdio;

 int f( int x )
 {
       // Error! internalFunc is not defined.
      return x + internalFunc();

      // oh but here it is... nested functions don't allow this
      int internalFunc()
      {
          return 314;
      }
 }
Err.. you've re-written your constructor as a free function? not the static opCall. Why? I would have expected this free function: int free_function( int x ) { // what do you know, not so 'static' after all! f instance = new f(x); int result = instance.result; // cleanup delete instance; return result; } void main() { int x = 42; x = free_function(x); writefln(x); }
That does work. Forces you to put the function outside of the class, but meh, it's just aesthetics/syntax sugar.
 I've gotta go.. so, I'll just post what I've said so far and see what 
 you  respond with.. I may reply again to the stuff below.. :)
 
 Regan
 
 In a trivial case like this all you have to do is move the nested
 function internalFunc to the top.  In other cases though, where you want
 to be able to places the functions where they intuitively belong, this
 becomes annoying.  This is that forward referencing issue I was talking
 about.

 Also, if 'f' were derived from another class, then the code executed 
 in  f's constructor would have access to the super class's members.  
 That's  more to do with OOP, but it's all hidden behind a static opCall.

 I suppose you could use a module function to construct and delete a  
 private class that gets used for it's own scope and inheritance.  I  
 worry that I am missing some detail that stopped me from just doing 
 that  before.

 Sean, perhaps you could share some of your uses for static opCall 
 since  I'm doing such a bad job at this?


 Only slightly related - I wonder if D's 'new' even implies heap  
 allocation as it is.  That might just be a dmd thing, but I am 
 looking  in the spec at Classes -> ctors/dtors, and it doesn't say 
 where they get  allocated.  Maybe someone who is good at searching the 
 spec can find if  it says where classes get allocated?
 My thought, as xs0 has mentioned as well, is that 'new' could be 
 defined  independant of those implementation details.  For example, 
 just say that  'new' will allocate a class instance, and that the 
 instance will be  cleaned up only after there are no more references 
 to that class.  The  only exception being explicit deletion.  Since 
 RAII gaurantees, AFAIK,  that there are no references leaked into code 
 that gets executed after  the scope is exited, then stack allocation 
 would work here.  I'm finding  it hard to imagine code that would 
 require an object to be in the heap's  address range or in the stack's 
 address range.  xs0 says there are other  cases in which a class can 
 be allocated on the stack without breaking  the gaurantees of no 
 premature deletion, and I wonder what they are.
Aug 02 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
 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
Aug 02 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Chad J wrote:
 Regan Heath wrote:
 
 Add the new RAII syntax  and not only does it not crash, but it 
 behaves just like a C++ program  would with A being destroyed at the 
 end of scope.
I hear that such syntax, in C++, means that 'A' will be stack allocated, which AFAIK does not imply RAII. One example I can think of that would break RAII is if the function gets inlined, then the stack allocated object may not be deleted until some point outside of the scope's end. It will /probably/ be deleted at the end of the function that the enclosing function was inlined into. I could be wrong about that though.
Uh, scopes and stack "frames" do not exist only for function frames. They exist for any instruction-block/scope. Such that: void func() { auto Foo fooa = new Foo; { auto Foo foob = new Foo; } // foob gets destroyed here ... } // fooa gets destroyed here So similarly, function inlining creates a scope/instruction-block , so that allocation behavior is preserved. So this code: int a = 2, b = 3; int r = sum(a, b); gets inlined to this: int a = 2, b = 3; int r; { r = a + b; } // De-alloc autos if there were any. -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 29 2006
parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Bruno Medeiros wrote:
 Chad J wrote:
 
 Regan Heath wrote:

 Add the new RAII syntax  and not only does it not crash, but it 
 behaves just like a C++ program  would with A being destroyed at the 
 end of scope.
I hear that such syntax, in C++, means that 'A' will be stack allocated, which AFAIK does not imply RAII. One example I can think of that would break RAII is if the function gets inlined, then the stack allocated object may not be deleted until some point outside of the scope's end. It will /probably/ be deleted at the end of the function that the enclosing function was inlined into. I could be wrong about that though.
Uh, scopes and stack "frames" do not exist only for function frames. They exist for any instruction-block/scope. Such that: void func() { auto Foo fooa = new Foo; { auto Foo foob = new Foo; } // foob gets destroyed here ... } // fooa gets destroyed here So similarly, function inlining creates a scope/instruction-block , so that allocation behavior is preserved. So this code: int a = 2, b = 3; int r = sum(a, b); gets inlined to this: int a = 2, b = 3; int r; { r = a + b; } // De-alloc autos if there were any.
Ah. Thanks for the info.
Aug 02 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Regan Heath wrote:
 On Tue, 25 Jul 2006 23:28:24 -0400, Chad J 
 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?
Are you saying it is intuitive because *it is the same syntax as C++* ?? I hope not, because being the same syntax as C++ not only does not make it intuitive, but it also likely has the inverse effect: making things un-intuitive. -- Bruno Medeiros - MSc. in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 29 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 29 Jul 2006 21:20:22 +0100, Bruno Medeiros  
<brunodomedeirosATgmail SPAM.com> wrote:
 Regan Heath wrote:
 On Tue, 25 Jul 2006 23:28:24 -0400, Chad J
 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?
Are you saying it is intuitive because *it is the same syntax as C++* ?? I hope not, because being the same syntax as C++ not only does not make it intuitive, but it also likely has the inverse effect: making things un-intuitive.
I was in fact wrong about the syntax being the same. That said, syntax and behaviour which is similar to C++ is intuitive (to C++ programmers). That's all I sugested (you need to read my statement in I was attempting to compare the 2 proposals: - absence of 'new' - use of keyword 'scope' or 'local' or <insert favourite keyword> encounter the RAII syntax, as far as I can see they'll either: 1. read some code using it. 2. want to implement RAII and will search the docs. I don't think either method is significantly better or worse in these 2 situations regardless of the programmers background. My mistake was that I thought the "absence of new" syntax was the same as the C++ syntax (for stack allocated, destroy at end of scope classes). This would have made it 'more' intuitive to the general population by virtue of being 'more' intuitive to the C++ programmers. In fact, if the suggested RAII syntax was: class A {} A a; //allocate RAII class then the C++ programmer, who wrote the above for his/her first D program wouldn't get an access violation (as they currently do) and would instead get the expected behaviour. An object (not allocated on the stack.. yet) whose destructor is called at end of scope. So, perhaps the RAII syntax should be this? It benefits C++ programmers a new keyword (as it's essentially the same thing) Regan
Jul 31 2006
prev sibling next sibling parent reply xs0 <xs0 xs0.com> writes:
 I say lets keep 'auto' for auto type inference (for the reasons you and 
 Don mention)
agreed.
 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.
Why would you want to deal with where the object is allocated? Besides speed, is there any reason at all to allocate on the stack? If you always type the same thing, the compiler is always free to choose the best location. If you restrict "new" to allocating on the heap, you prevent the compiler from optimizing (by allocating on the stack) whenever it determines it's safe to do so (scoped variables are not the only such case). Imho, "scope" is a perfect keyword for scoped variables/classes, for reasons already stated (already exists, good meaning, explicit). A missing "new" is not a good keyword ;) By the way, I think it would be wise to require references to scope-classes also be tagged with scope, so it'd be harder to miss that not-so-insignificant detail about them..
 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.
But there is utility in static opCall in structs; having them there but not in classes doesn't sound to cool/consistent.. xs0
Jul 26 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 26 Jul 2006 11:58:31 +0200, xs0 <xs0 xs0.com> wrote:
 I say lets keep 'auto' for auto type inference (for the reasons you and  
 Don mention)
agreed.
 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.
Why would you want to deal with where the object is allocated?
My post _must_ have been missleading (more than one person thinks I want stack allocation). I don't want stack allocation. I was simply raising the possibility of stack allocation as a possibly beneficial side-effect of removing 'new' (which implies/required heap allocation, AFAICS)
 Besides speed, is there any reason at all to allocate on the stack?
Speed isn't a good enough reason?
 If you always type the same thing, the compiler is always free to choose  
 the best location. If you restrict "new" to allocating on the heap, you  
 prevent the compiler from optimizing (by allocating on the stack)  
 whenever it determines it's safe to do so (scoped variables are not the  
 only such case).
Is it even possible for 'new' to allocate on the stack? I mean the stack vanishes when the function exits, therefore isn't 'new' restricted to the heap?
 Imho, "scope" is a perfect keyword for scoped variables/classes, for  
 reasons already stated (already exists, good meaning, explicit). A  
 missing "new" is not a good keyword ;)
I disagree, see my recent reply to "Chad J", specifically the scenarios involving the C++ and Java programmers.
 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.
But there is utility in static opCall in structs; having them there but not in classes doesn't sound to cool/consistent..
The only utility in static opCall is to emulate a constructor. Why not replace them with a constructor (ie. rename "static opCall" to "this"). Then, remove static opCall altogether. Regan
Jul 26 2006
next sibling parent reply Tommie Gannert <tomime gannert.se> writes:
 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.
But there is utility in static opCall in structs; having them there but not in classes doesn't sound to cool/consistent..
The only utility in static opCall is to emulate a constructor. Why not replace them with a constructor (ie. rename "static opCall" to "this"). Then, remove static opCall altogether.
I haven't been following this, but static opCall sounds an awful lot like a function call to a function with static variables... I must join the "who would want such a thing"-side. /T
Jul 26 2006
parent Sean Kelly <sean f4.ca> writes:
Tommie Gannert wrote:
 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.
But there is utility in static opCall in structs; having them there but not in classes doesn't sound to cool/consistent..
The only utility in static opCall is to emulate a constructor. Why not replace them with a constructor (ie. rename "static opCall" to "this"). Then, remove static opCall altogether.
I haven't been following this, but static opCall sounds an awful lot like a function call to a function with static variables... I must join the "who would want such a thing"-side.
Support for static operator functions can be useful for refactoring code in some cases, or for some odd template uses. I don't use the feature very often, but it's nice to have available. Sean
Jul 27 2006
prev sibling parent reply xs0 <xs0 xs0.com> writes:
Regan Heath wrote:
 On Wed, 26 Jul 2006 11:58:31 +0200, xs0 <xs0 xs0.com> wrote:
 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.
Why would you want to deal with where the object is allocated?
My post _must_ have been missleading (more than one person thinks I want stack allocation). I don't want stack allocation. I was simply raising the possibility of stack allocation as a possibly beneficial side-effect of removing 'new' (which implies/required heap allocation, AFAICS)
'new' doesn't imply/require that heap allocation actually be done, it just requires the result to behave as if it was (look up "escape analysis")
 Besides speed, is there any reason at all to allocate on the stack?
Speed isn't a good enough reason?
Speed is a good reason to use stack allocation. But that is also a good reason to let the compiler determine where to place an object, not the programmer.
 If you always type the same thing, the compiler is always free to 
 choose the best location. If you restrict "new" to allocating on the 
 heap, you prevent the compiler from optimizing (by allocating on the 
 stack) whenever it determines it's safe to do so (scoped variables are 
 not the only such case).
Is it even possible for 'new' to allocate on the stack? I mean the stack vanishes when the function exits, therefore isn't 'new' restricted to the heap?
No. There are many cases where the object is not actually required to be on the heap.
 Imho, "scope" is a perfect keyword for scoped variables/classes, for 
 reasons already stated (already exists, good meaning, explicit). A 
 missing "new" is not a good keyword ;)
I disagree, see my recent reply to "Chad J", specifically the scenarios involving the C++ and Java programmers.
Well, I'm a Java programmer and if I see A a = A(); I see a function call that returns something of type A. If I see auto a = A(); I definitely see a function call. You'll never convince me that the lack of "new" is a good indication of anything, much less of the fact that it's a scoped variable.
 The only utility in static opCall is to emulate a constructor. Why not 
 replace them with a constructor (ie. rename "static opCall" to "this"). 
 Then, remove static opCall altogether.
Emulating a constructor is not the only utility, it's emulating an arbitrary function. xs0
Jul 27 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 27 Jul 2006 15:31:24 +0200, xs0 <xs0 xs0.com> wrote:
 Regan Heath wrote:
 On Wed, 26 Jul 2006 11:58:31 +0200, xs0 <xs0 xs0.com> wrote:
 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.
Why would you want to deal with where the object is allocated?
My post _must_ have been missleading (more than one person thinks I want stack allocation). I don't want stack allocation. I was simply raising the possibility of stack allocation as a possibly beneficial side-effect of removing 'new' (which implies/required heap allocation, AFAICS)
'new' doesn't imply/require that heap allocation actually be done, it just requires the result to behave as if it was (look up "escape analysis")
Ok.
 Besides speed, is there any reason at all to allocate on the stack?
Speed isn't a good enough reason?
Speed is a good reason to use stack allocation. But that is also a good reason to let the compiler determine where to place an object, not the programmer.
Exactly. I never suggested otherwise :)
 If you always type the same thing, the compiler is always free to  
 choose the best location. If you restrict "new" to allocating on the  
 heap, you prevent the compiler from optimizing (by allocating on the  
 stack) whenever it determines it's safe to do so (scoped variables are  
 not the only such case).
Is it even possible for 'new' to allocate on the stack? I mean the stack vanishes when the function exits, therefore isn't 'new' restricted to the heap?
No. There are many cases where the object is not actually required to be on the heap.
Example?
 Imho, "scope" is a perfect keyword for scoped variables/classes, for  
 reasons already stated (already exists, good meaning, explicit). A  
 missing "new" is not a good keyword ;)
I disagree, see my recent reply to "Chad J", specifically the scenarios involving the C++ and Java programmers.
Well, I'm a Java programmer and if I see A a = A(); I see a function call that returns something of type A. If I see auto a = A(); I definitely see a function call. You'll never convince me that the lack of "new" is a good indication of anything, much less of the fact that it's a scoped variable.
Have you read my other post? Are you telling me you have a "closed mind"? If so, this discussion is pointless.
 The only utility in static opCall is to emulate a constructor. Why not  
 replace them with a constructor (ie. rename "static opCall" to "this").  
 Then, remove static opCall altogether.
Emulating a constructor is not the only utility, it's emulating an arbitrary function.
Yes, but it's a 'static' function. See my other post WRT "information hiding", for that purpose it's actually better to use an actual static function. Regan
Jul 27 2006
parent reply xs0 <xs0 xs0.com> writes:
Regan Heath wrote:

 'new' doesn't imply/require that heap allocation actually be done, it 
 just requires the result to behave as if it was (look up "escape 
 analysis")
Ok.
 Besides speed, is there any reason at all to allocate on the stack?
Speed isn't a good enough reason?
Speed is a good reason to use stack allocation. But that is also a good reason to let the compiler determine where to place an object, not the programmer.
Exactly. I never suggested otherwise :)
You did - you propose that using "new" forces the allocation on the heap, while not using it leaves the choice to the compiler (however, the variable is then also scoped/raii/auto/banana, so there's not much choice anyway).
  Is it even possible for 'new' to allocate on the stack? I mean the 
 stack vanishes when the function exits, therefore isn't 'new' 
 restricted to the heap?
No. There are many cases where the object is not actually required to be on the heap.
Example?
Did you look up escape analysis like I suggested? Anyway, besides the obvious scoped/raii/auto/banana variables, here's a simple example: void foo(Object a) { writefln("%s", a.toString()); } main() { foo(new Whatever()); } There's no reason why Whatever would have to be on the heap.
 Imho, "scope" is a perfect keyword for scoped variables/classes, for 
 reasons already stated (already exists, good meaning, explicit). A 
 missing "new" is not a good keyword ;)
I disagree, see my recent reply to "Chad J", specifically the scenarios involving the C++ and Java programmers.
Well, I'm a Java programmer and if I see A a = A(); I see a function call that returns something of type A. If I see auto a = A(); I definitely see a function call. You'll never convince me that the lack of "new" is a good indication of anything, much less of the fact that it's a scoped variable.
Have you read my other post? Are you telling me you have a "closed mind"? If so, this discussion is pointless.
Dude, what's wrong with you? Your argument was that Java programmers would see an allocating expression without "new" or any other keyword, and somehow magically determine that there's something to be learned. I responded by saying that they (or me) wouldn't even see it as an allocating expression, and for that I have a closed mind? You know, you're probably right, this discussion is pointless, like so many others you participate in. And I still don't get how you can even think that "" can be a better indication of anything than "scope" (or any other keyword). When you see an empty paper, does a thought "oooh, I need to learn about D's scoped variables" spring to your mind?
 The only utility in static opCall is to emulate a constructor. Why 
 not replace them with a constructor (ie. rename "static opCall" to 
 "this"). Then, remove static opCall altogether.
Emulating a constructor is not the only utility, it's emulating an arbitrary function.
Yes, but it's a 'static' function. See my other post WRT "information hiding", for that purpose it's actually better to use an actual static function.
Without even reading your other post, I never said it's always better to use static opCall. I'm just saying there are cases where it's cool to have. But, this is basically a separate discussion anyway, so no need to continue with it. xs0
Jul 28 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 28 Jul 2006 12:12:49 +0200, xs0 <xs0 xs0.com> wrote:
 Regan Heath wrote:

 'new' doesn't imply/require that heap allocation actually be done, it  
 just requires the result to behave as if it was (look up "escape  
 analysis")
Ok.
 Besides speed, is there any reason at all to allocate on the stack?
Speed isn't a good enough reason?
Speed is a good reason to use stack allocation. But that is also a good reason to let the compiler determine where to place an object, not the programmer.
Exactly. I never suggested otherwise :)
You did - you propose that using "new" forces the allocation on the heap, while not using it leaves the choice to the compiler (however, the variable is then also scoped/raii/auto/banana, so there's not much choice anyway).
I'm arguing semantics perhaps but all I did was say that it 'implied' heap allocation 'in my opinion'. My exact words were..
 Quoting "Regan Heath"..
 '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.
Until you gave the example below (thanks for that) I did suspect that it was required for 'new' to heap allocate because stack allocation only 'lives' as long as the scope in which it's allocated. So, stack allocation could be done for 'new' in certain cases (like the example below) to optimise, cool. To me 'new' still 'implies' heap allocation. But, now I know that there are some situations where the compiler could stack allocate, situations where the object allocated by 'new' only 'lives' as long as the current scope.
  Is it even possible for 'new' to allocate on the stack? I mean the  
 stack vanishes when the function exits, therefore isn't 'new'  
 restricted to the heap?
No. There are many cases where the object is not actually required to be on the heap.
Example?
Did you look up escape analysis like I suggested?
Yes. But I still wanted an example from you :)
 Anyway, besides the obvious scoped/raii/auto/banana variables, here's a  
 simple example:

 void foo(Object a)
 {
      writefln("%s", a.toString());
 }

 main()
 {
      foo(new Whatever());
 }

 There's no reason why Whatever would have to be on the heap.
Nice. So an optimising compiler may choose to allocate 'a' on the stack. It can do that because the object only 'lives' as long as the scope of the function 'foo', correct?
 Imho, "scope" is a perfect keyword for scoped variables/classes, for  
 reasons already stated (already exists, good meaning, explicit). A  
 missing "new" is not a good keyword ;)
I disagree, see my recent reply to "Chad J", specifically the scenarios involving the C++ and Java programmers.
Well, I'm a Java programmer and if I see A a = A(); I see a function call that returns something of type A. If I see auto a = A(); I definitely see a function call. You'll never convince me that the lack of "new" is a good indication of anything, much less of the fact that it's a scoped variable.
Have you read my other post? Are you telling me you have a "closed mind"? If so, this discussion is pointless.
Dude, what's wrong with you? Your argument was that Java programmers would see an allocating expression without "new" or any other keyword, and somehow magically determine that there's something to be learned. I responded by saying that they (or me) wouldn't even see it as an allocating expression, and for that I have a closed mind?
Your comment "You'll never convince me.. " caused my response wrt "closed mind". I meant no offence by it.
 You know, you're probably right, this discussion is pointless, like so  
 many others you participate in.
You seem to be atributing me with some sort of malice towards you, that's simply not the case. I avoid posting anything while I'm angry as I tend to regret it. I wasn't even angry or annoyed in this case, just curious. I seem to have angered you, I apologise for that.
 And I still don't get how you can even think that "" can be a better  
 indication of anything than "scope" (or any other keyword).
Then I'm doing a bad job of explaining. I believe you've missunderstood some of what I've tried to say (also my fault for choosing the wrong words to explain it)
 The only utility in static opCall is to emulate a constructor. Why  
 not replace them with a constructor (ie. rename "static opCall" to  
 "this"). Then, remove static opCall altogether.
Emulating a constructor is not the only utility, it's emulating an arbitrary function.
Yes, but it's a 'static' function. See my other post WRT "information hiding", for that purpose it's actually better to use an actual static function.
Without even reading your other post, I never said it's always better to use static opCall. I'm just saying there are cases where it's cool to have. But, this is basically a separate discussion anyway, so no need to continue with it.
Actually I think it's important to this discussion. If static opCall is truly useful it makes the 'absence of new' idea rather worse than using a keyword. Among other things I'm trying to determine when/where static opCall is used, and why it's used in favour of another method (or even if one such method exists). I also wanted to know when 'new' could do something other than heap allocate, you've answered that one, thanks. Regan
Jul 31 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Regan Heath wrote:
 On Tue, 25 Jul 2006 10:17:13 -0700, kris <foo bar.com> wrote:
 Don has a good point: changing to "var" would cause conflict with 
 existing variable-names.

 Chad et. al. also have a good point about the conflict regarding 
 static opCall() (via the lack of a "new" keyword). I suspect many 
 people find the use of "new" to be indicative of allocation, and 
 breaking this consistency may have a detrimental effect? Further, it 
 was noted that a missing "new" can only be used at the instantiation 
 site -- not at the class decl -- thus, D would be losing an existing 
 feature.

 I suspect you could count the current number of raii-class uses on a 
 few hands, whereas the use of "auto" for implied-type is pretty darned 
 popular -- and rightly so, since it's really very, very useful. 
 Changing the raii style to use a different keyword, whilst retaining 
 implied-type "auto" would be an almost imperceptible change?

 Thus, it would appear to make sense to retain "auto" for implied-type, 
 and introduce something *else* for automatic cleanup at end-of-scope 
 (and also as a class attribute). how about reusing the "scope" keyword?

 void main()
 {
    auto i = 10;
    auto foo = new Foo;
    auto scope bar = new Bar;
    auto scope wumpus = new Wumpus;
 }

 class Foo {}

 class Bar {}

 scope class Wumpus {}
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 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
I don't like the no-allocator-keyword proposal. There are the problems: * the lack of static opCall (which I don't have experience with, so I'll leave the arguing about the usefulness of it to others). * less clear in the code that an allocation (stack or otherwise) is taking place. (somewhat subjective/aesthetical point I guess) But most importantly: * You can't make auto objects out of objects allocated with a function (like a factory method) instead of inline allocation. For example, the following cannot be made with a no-allocator-keyword syntax: auto Foo foo = SomeFactory.newFoo(..); // can't make an auto here auto char[] a = read(filename); // can't make an auto here -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 29 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 29 Jul 2006 22:17:07 +0100, Bruno Medeiros  
<brunodomedeirosATgmail SPAM.com> wrote:
 But most importantly:
 * You can't make auto objects out of objects allocated with a function
 (like a factory method) instead of inline allocation. For example, the
 following cannot be made with a no-allocator-keyword syntax:
    auto Foo foo = SomeFactory.newFoo(..); // can't make an auto here
    auto char[] a = read(filename); // can't make an auto here
Good point. That's a big problem. Regan
Jul 31 2006
prev sibling next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
I vote for banana!

or scope.. seems good to reuse it; without parentheses after scope keywo=
rd  =

implying `end of scope destruction`.


On Tue, 25 Jul 2006 13:17:13 -0400, kris <foo bar.com> wrote:

 Don has a good point: changing to "var" would cause conflict with  =
 existing variable-names.

 Chad et. al. also have a good point about the conflict regarding stati=
c =
 opCall() (via the lack of a "new" keyword). I suspect many people find=
=
 the use of "new" to be indicative of allocation, and breaking this  =
 consistency may have a detrimental effect? Further, it was noted that =
a =
 missing "new" can only be used at the instantiation site -- not at the=
=
 class decl -- thus, D would be losing an existing feature.

 I suspect you could count the current number of raii-class uses on a f=
ew =
 hands, whereas the use of "auto" for implied-type is pretty darned  =
 popular -- and rightly so, since it's really very, very useful. Changi=
ng =
 the raii style to use a different keyword, whilst retaining implied-ty=
pe =
 "auto" would be an almost imperceptible change?

 Thus, it would appear to make sense to retain "auto" for implied-type,=
=
 and introduce something *else* for automatic cleanup at end-of-scope  =
 (and also as a class attribute). how about reusing the "scope" keyword=
?
 void main()
 {
    auto i =3D 10;
    auto foo =3D new Foo;
    auto scope bar =3D new Bar;
    auto scope wumpus =3D new Wumpus;
 }

 class Foo {}

 class Bar {}

 scope class Wumpus {}
Jul 25 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Chris Miller" <chris dprogramming.com> wrote in message 
news:op.tc91g1fjpo9bzi moe...
 I vote for banana!
banana++
 or scope.. seems good to reuse it; without parentheses after scope keyword 
 implying `end of scope destruction`.
I like scope for RAII too. Wonder who originally suggested that *cough*cough* ;)
Jul 27 2006
parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Jarrett Billingsley wrote:
 "Chris Miller" <chris dprogramming.com> wrote in message 
 news:op.tc91g1fjpo9bzi moe...
 I vote for banana!
banana++
No!! I often use banana as an identifier in many of my programs! :P -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 29 2006
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
vote++;
//me likes

kris wrote:
 Don has a good point: changing to "var" would cause conflict with 
 existing variable-names.
 
 Chad et. al. also have a good point about the conflict regarding static 
 opCall() (via the lack of a "new" keyword). I suspect many people find 
 the use of "new" to be indicative of allocation, and breaking this 
 consistency may have a detrimental effect? Further, it was noted that a 
 missing "new" can only be used at the instantiation site -- not at the 
 class decl -- thus, D would be losing an existing feature.
 
 I suspect you could count the current number of raii-class uses on a few 
 hands, whereas the use of "auto" for implied-type is pretty darned 
 popular -- and rightly so, since it's really very, very useful. Changing 
 the raii style to use a different keyword, whilst retaining implied-type 
 "auto" would be an almost imperceptible change?
 
 Thus, it would appear to make sense to retain "auto" for implied-type, 
 and introduce something *else* for automatic cleanup at end-of-scope 
 (and also as a class attribute). how about reusing the "scope" keyword?
 
 void main()
 {
   auto i = 10;
   auto foo = new Foo;
   auto scope bar = new Bar;
   auto scope wumpus = new Wumpus;
 }
 
 class Foo {}
 
 class Bar {}
 
 scope class Wumpus {}
 
 
 
 
 
 
Jul 26 2006
parent reply "John Reimer" <terminal.node gmail.com> writes:
On Wed, 26 Jul 2006 02:52:06 -0700, Hasan Aljudy <hasan.aljudy gmail.com>  
wrote:

 vote++;
 //me likes
I am sympathetic to the "scope" suggestion also. People have to remember that Walter doesn't like adding any new keywords. Reuse of "scope" may be the best solution here. Are there any drawbacks? Does it fit the intended meaning and purpose appropriately? It seems to. -JJR
Jul 27 2006
parent reply Sean Kelly <sean f4.ca> writes:
John Reimer wrote:
 On Wed, 26 Jul 2006 02:52:06 -0700, Hasan Aljudy 
 <hasan.aljudy gmail.com> wrote:
 
 vote++;
 //me likes
I am sympathetic to the "scope" suggestion also. People have to remember that Walter doesn't like adding any new keywords. Reuse of "scope" may be the best solution here. Are there any drawbacks? Does it fit the intended meaning and purpose appropriately? It seems to.
Given the suggested placement, I assume it would be illegal to reassign a 'scope' reference to another object? ie. class C {} scope C var = new C(); var = new C(); Assuming a reassignment is allowed, I assume the original object would not be destroyed on scope exit? Basically, I'm wondering whether the 'scope' qualifier is attached to the reference or to the referent. Sean
Jul 27 2006
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Sean Kelly wrote:
 John Reimer wrote:
 
 On Wed, 26 Jul 2006 02:52:06 -0700, Hasan Aljudy 
 <hasan.aljudy gmail.com> wrote:

 vote++;
 //me likes
I am sympathetic to the "scope" suggestion also. People have to remember that Walter doesn't like adding any new keywords. Reuse of "scope" may be the best solution here. Are there any drawbacks? Does it fit the intended meaning and purpose appropriately? It seems to.
Given the suggested placement, I assume it would be illegal to reassign a 'scope' reference to another object? ie. class C {} scope C var = new C(); var = new C(); Assuming a reassignment is allowed, I assume the original object would not be destroyed on scope exit? Basically, I'm wondering whether the 'scope' qualifier is attached to the reference or to the referent. Sean
Maybe we could decide that based on the keyword's placement: class C { int m_i; this(int i) { m_i = i; } int i() { return m_i; } } scope C a = new C(1); // Destroy 'a' at end of scope C b = a; // b is another reference to 1. It will be invalid at the // end of scope, except: a = new C(2); // No, whoops! Destroy 2 at end of scope. // 1 is now referenced by b alone. return b; // Allowed! The reference 'a' will no longer destroy 1. return a; // NOT allowed! a is a scoped reference The alternative: C a = scope new C(1); // Destroy 1 at end of scope. C b = a; // b is another reference to 1, which will be destroyed // at the end of scope. a = new C(2); // A new, plain-old GCed instance. return b; // NOT allowed! 1 is invalid after this scope. return a; // Okay. a is a reference to a regular object. Maybe we could allow both? -- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 27 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Kirk McDonald wrote:
 Maybe we could decide that based on the keyword's placement:
 
 class C {
     int m_i;
     this(int i) { m_i = i; }
     int i() { return m_i; }
 }
 
 scope C a = new C(1); // Destroy 'a' at end of scope
 C b = a; // b is another reference to 1. It will be invalid at the
          // end of scope, except:
 a = new C(2); // No, whoops! Destroy 2 at end of scope.
               // 1 is now referenced by b alone.
 return b; // Allowed! The reference 'a' will no longer destroy 1.
 return a; // NOT allowed! a is a scoped reference
 
 The alternative:
 
 C a = scope new C(1); // Destroy 1 at end of scope.
 C b = a; // b is another reference to 1, which will be destroyed
          // at the end of scope.
 a = new C(2); // A new, plain-old GCed instance.
 return b; // NOT allowed! 1 is invalid after this scope.
 return a; // Okay. a is a reference to a regular object.
 
 Maybe we could allow both?
 
Sounds reasonable to me, and potentially quite useful (even if often primarily for self-documenting code design, as I suspect in the vast majority of use-cases the effect will be identical). I also think it might very well be reasonable to disallow using 'scope' in tandem with either of 'static' or 'const' as the meaning is... well, questionable. Except perhaps for 'static' in the sole case of recursive functions, in which case I suppose the entity exists until the entire call-stack has unwound. Potentially useful. Allowing 'scope auto' seems harmless, although redundant since 'scope' as a storage class should allow for type-inference via precedance alone. -- Chris Nicholson-Sauls
Jul 28 2006
prev sibling next sibling parent Juan Jose Comellas <jcomellas gmail.com> writes:
I think "local" may be a better name. At least I don't think I have ever
used a variable with that name.


kris wrote:

 Don has a good point: changing to "var" would cause conflict with
 existing variable-names.
 
 Chad et. al. also have a good point about the conflict regarding static
 opCall() (via the lack of a "new" keyword). I suspect many people find
 the use of "new" to be indicative of allocation, and breaking this
 consistency may have a detrimental effect? Further, it was noted that a
 missing "new" can only be used at the instantiation site -- not at the
 class decl -- thus, D would be losing an existing feature.
 
 I suspect you could count the current number of raii-class uses on a few
 hands, whereas the use of "auto" for implied-type is pretty darned
 popular -- and rightly so, since it's really very, very useful. Changing
 the raii style to use a different keyword, whilst retaining implied-type
 "auto" would be an almost imperceptible change?
 
 Thus, it would appear to make sense to retain "auto" for implied-type,
 and introduce something *else* for automatic cleanup at end-of-scope
 (and also as a class attribute). how about reusing the "scope" keyword?
 
 void main()
 {
    auto i = 10;
    auto foo = new Foo;
    auto scope bar = new Bar;
    auto scope wumpus = new Wumpus;
 }
 
 class Foo {}
 
 class Bar {}
 
 scope class Wumpus {}
Jul 27 2006
prev sibling next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
 void main()
 {
   auto i = 10;
   auto foo = new Foo;
   auto scope bar = new Bar;
   auto scope wumpus = new Wumpus;
 }
Conceptually 'auto' as a scope variable indicator is redundant. In 'ideal D world' struct shall have ctor/dtor and entities required stack allocation shall be declared as structs - not classes. So if you need pure stack allocated object use struct with dtor. And if you need class instance to be managed by stack variable use simple struct based smart pointer: struct local(T) { T ptr; void opAssign(T t) { ptr = t; } ~this() { delete ptr; } } void main() { local!(Bar) bar = new Bar; // opAssign invovation ... do something ... } // implicit dtor invocation happens here -> delete bar.ptr Andrew Fedoniouk. http://terrainformatica.com
Jul 27 2006
prev sibling next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
kris wrote:
 Thus, it would appear to make sense to retain "auto" for implied-type, 
 and introduce something *else* for automatic cleanup at end-of-scope 
 (and also as a class attribute). how about reusing the "scope" keyword?
 
 void main()
 {
   auto i = 10;
   auto foo = new Foo;
   auto scope bar = new Bar;
   auto scope wumpus = new Wumpus;
 }
I've argued in the past about being able to elide the 'new' keyword entirely. I like the Python semantics, where 'calling' a class is synonymous with calling a factory function that returns instances of the class. The 'new' keyword is just redundant... until you remember that D has static opCall. So, without imposing an arbitrary restriction of disallowing static opCall for classes (but not for structs!), or saying e.g. that you have to say "new" for any class with static opCall defined for it (which would just be a huge headache)... I think this is the best solution. -- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 27 2006
prev sibling next sibling parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
kris wrote:

 Don has a good point: changing to "var" would cause conflict with existing
 variable-names.
 
 Chad et. al. also have a good point about the conflict regarding static
 opCall() (via the lack of a "new" keyword). I suspect many people find the
 use of "new" to be indicative of allocation, and breaking this consistency
 may have a detrimental effect? Further, it was noted that a missing "new" can
 only be used at the instantiation site -- not at the class decl -- thus, D
 would be losing an existing feature.
Agreed. I also don't think 'missing new' proposal is good.
 
 I suspect you could count the current number of raii-class uses on a few
 hands, whereas the use of "auto" for implied-type is pretty darned popular --
 and rightly so, since it's really very, very useful. Changing the raii style
 to use a different keyword, whilst retaining implied-type "auto" would be an
 almost imperceptible change?
 
 Thus, it would appear to make sense to retain "auto" for implied-type, and
 introduce something else for automatic cleanup at end-of-scope (and also as a
 class attribute). how about reusing the "scope" keyword?
 
 void main()
 {
   auto i = 10;
   auto foo = new Foo;
   auto scope bar = new Bar;
   auto scope wumpus = new Wumpus;
 }
Looks ok to me, but should be in the reverse order I think: -------------------------------------------------------------- void main() { auto i = 10; auto foo = new Foo; scope auto bar = new Bar; scope auto wumpus = new Wumpus; } -------------------------------------------------------------- and with the current D policy of type inference when 'static' or 'const' is enough for declaration this should be also legal: -------------------------------------------------------------- scope bar = new Bar; -------------------------------------------------------------- -- AKhropov
Jul 27 2006
parent reply kris <foo bar.com> writes:
Andrei Khropov wrote:
 kris wrote:
 
 
Don has a good point: changing to "var" would cause conflict with existing
variable-names.

Chad et. al. also have a good point about the conflict regarding static
opCall() (via the lack of a "new" keyword). I suspect many people find the
use of "new" to be indicative of allocation, and breaking this consistency
may have a detrimental effect? Further, it was noted that a missing "new" can
only be used at the instantiation site -- not at the class decl -- thus, D
would be losing an existing feature.
Agreed. I also don't think 'missing new' proposal is good.
Someone noted that x = SomeName(); is confusing, since it doesn't convey whether a class is instantiated, or a function is called. That's part of the issue noted above, and it becomes worse when dropping the optional parens x = SomeName; Whereas it is still perfectly meaningful when using new instead: x = new SomeName;
I suspect you could count the current number of raii-class uses on a few
hands, whereas the use of "auto" for implied-type is pretty darned popular --
and rightly so, since it's really very, very useful. Changing the raii style
to use a different keyword, whilst retaining implied-type "auto" would be an
almost imperceptible change?

Thus, it would appear to make sense to retain "auto" for implied-type, and
introduce something else for automatic cleanup at end-of-scope (and also as a
class attribute). how about reusing the "scope" keyword?

void main()
{
  auto i = 10;
  auto foo = new Foo;
  auto scope bar = new Bar;
  auto scope wumpus = new Wumpus;
}
Looks ok to me, but should be in the reverse order I think: -------------------------------------------------------------- void main() { auto i = 10; auto foo = new Foo; scope auto bar = new Bar; scope auto wumpus = new Wumpus; } -------------------------------------------------------------- and with the current D policy of type inference when 'static' or 'const' is enough for declaration this should be also legal: -------------------------------------------------------------- scope bar = new Bar; --------------------------------------------------------------
Yes, thankyou ~ I'd forgotton about that groovy option: void main() { auto i = 10; auto foo = new Foo; scope bar = new Bar; scope wumpus = new Wumpus; } class Foo {} class Bar {} scope class Wumpus {} // can only be used as a scope'd instance
Jul 28 2006
parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
kris wrote:

 Someone noted that
 
  x = SomeName();
 
 is confusing, since it doesn't convey whether a class is instantiated, or a
 function is called. That's part of the issue noted above, and it becomes
 worse when dropping the optional parens
 
  x = SomeName;
 
 Whereas it is still perfectly meaningful when using new instead:
 
  x = new SomeName;
Yes, that's an essential flaw in this proposal. Another one was mentioned in http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/40740 : <quote> But how does this proposed syntax handle variable-length arrays? char[] a = read(filename); Is 'a' destroyed at end of scope? </quote> So we'll lose the ability to initialize scope variables by function return value. -- AKhropov
Jul 28 2006
prev sibling next sibling parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
<IMHO>

I recently thought about using 'scoped' instead of 'scope'.
Yes, it's one extra letter but improved readability (IMHO):

----------------------------------------------------
  scope i = 1;    // is read like 'i is a scope'
----------------------------------------------------
  scoped i = 1;    // is read like 'i is scoped' 
----------------------------------------------------

and
----------------------------------------------------
  scope class Bar{ ... 
----------------------------------------------------
  scoped class Bar{ ...   // is read like 'Bar is a scoped class' 
----------------------------------------------------


and current uses of scope are also replaced (also it's consistent with the form
'synchronized')
:

----------------------------------------------------
	scope(exit) Statement
	scope(success) Statement
	scope(failure) Statement
----------------------------------------------------
changed to
----------------------------------------------------
	scoped(exit) Statement   // is read like 'this statement is scoped at exit'
	scoped(success) Statement
	scoped(failure) Statement
----------------------------------------------------

(there's no 'scoped' verb in English AFAIK but it looks very natural and
understandable)

</IMHO>

Does anybody use 'scoped' as identifier?

-- 
AKhropov
Jul 28 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
kris wrote:
 Don has a good point: changing to "var" would cause conflict with 
 existing variable-names.
 
[...]
 
 I suspect you could count the current number of raii-class uses on a few 
 hands, whereas the use of "auto" for implied-type is pretty darned 
 popular -- and rightly so, since it's really very, very useful. Changing 
 the raii style to use a different keyword, whilst retaining implied-type 
 "auto" would be an almost imperceptible change?
 
 Thus, it would appear to make sense to retain "auto" for implied-type, 
 and introduce something *else* for automatic cleanup at end-of-scope 
 (and also as a class attribute). how about reusing the "scope" keyword?
 
 void main()
 {
   auto i = 10;
   auto foo = new Foo;
   auto scope bar = new Bar;
   auto scope wumpus = new Wumpus;
 }
 
 class Foo {}
 
 class Bar {}
 
 scope class Wumpus {}
 
Up to now, I favored the following keyword proposals: "auto" -> for RAII (autoraii or raiiauto) "var" -> for implicit type deduction. (autotype) The idea that autotype is the most used auto notion, and as such should be the one not to change it's keyword has no support from me. (Although I agree Walter I very resilient towards keyword changes...) When I think the name "auto", I think the most close meaning is that of automatic allocation/decallocation (raiiauto) and not implicit type deduction. And I quite deslike the name "scope" (or even "scoped") for raiiauto, (subjective point) As for autotype, exactly because it is used often I liked the fact that 3.0. But I do agree there is some strangeness to see "var" used as such keyword for type deduction, so I wasn't 100% happy. How about "def" for autotype keyword? It's still one char shorter, and I think the name is pretty nice: def n = 42; def foo = new Foo(); The syntax similarity to dynamic languages is also somewhat... appealing :) -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 29 2006