www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Walter: Before you go and implement the new RAII syntax..

reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
This is what I'm talking about:

Foo f = Foo(); // RAII
Foo g = new Foo(); // Normal

Can we all discuss this?  I'm sorry, but that syntax is just too easy to 
mess up / miss.  I'm surprised that you, someone who is very much against 
"secret things happening" would be a proponent of this syntax.  It's just 
too nonobvious.  (And as a minor point, this also makes it impossible to 
make a static opCall with a class.)

How about instead, we keep auto to mean a RAII reference, and we take the C# 
route for type inference and come up with a "var" keyword which would be a 
"type placeholder".  That is:

var f = new Foo(); // Normal
auto var g = new Foo(); // RAII

And as you can see, this gets rid of thee "auto auto" problem.  Not to 
mention it gets rid of the very common misunderstanding that currently, 
"auto" is somehow used for type inference, when in fact it's simply the use 
of a storage class without a type that invokes type inference.

This, or maybe we could use a "stack" or "local" or "raii" keyword in place 
of the "new":

Foo f = stack Foo();
Foo g = local Foo();
Foo h = raii Foo();

Something.  Anything would be better than the "new or nothing" syntax. 
Sep 04 2006
next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 5 Sep 2006 00:55:56 -0400, Jarrett Billingsley wrote:

 This is what I'm talking about:
 
 Foo f = Foo(); // RAII
 Foo g = new Foo(); // Normal
 
 Can we all discuss this?  I'm sorry, but that syntax is just too easy to 
 mess up / miss.  I'm surprised that you, someone who is very much against 
 "secret things happening" would be a proponent of this syntax.  It's just 
 too nonobvious.  (And as a minor point, this also makes it impossible to 
 make a static opCall with a class.)
 
 How about instead, we keep auto to mean a RAII reference, and we take the C# 
 route for type inference and come up with a "var" keyword which would be a 
 "type placeholder".  That is:
 
 var f = new Foo(); // Normal
 auto var g = new Foo(); // RAII
 
 And as you can see, this gets rid of thee "auto auto" problem.  Not to 
 mention it gets rid of the very common misunderstanding that currently, 
 "auto" is somehow used for type inference, when in fact it's simply the use 
 of a storage class without a type that invokes type inference.
 
 This, or maybe we could use a "stack" or "local" or "raii" keyword in place 
 of the "new":
 
 Foo f = stack Foo();
 Foo g = local Foo();
 Foo h = raii Foo();
 
 Something.  Anything would be better than the "new or nothing" syntax.

I strongly agree with Jarrett. Foo f = <NEW> Foo(); where <NEW> can be either 'new' or 'local', or even 'new local' but never omitted, when invoking the class constructor. The static opCall is probably not valuable and if removed I wouldn't mind, but this still would not justify omitting 'new' either. BTW, I'm not wedded to 'local' but something, ... anything, that explicitly informs the reader that the object will be destroyed when it goes out of scope is needed. Leaving it out is not a good user interface. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 5/09/2006 2:57:59 PM
Sep 04 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Derek Parnell wrote:
 
 I strongly agree with Jarrett. 
 
      Foo f = <NEW> Foo();
 
   where <NEW> can be either 'new' or 'local', or even 'new local' but never
 omitted, when invoking the class constructor. The static opCall is probably
 not valuable and if removed I wouldn't mind, but this still would not
 justify omitting 'new' either.
 
 BTW, I'm not wedded to 'local' but something, ... anything, that explicitly
 informs the reader that the object will be destroyed when it goes out of
 scope is needed. Leaving it out is not a good user interface.

If there's to be a symbol to signify "stack allocation" then it should be in place of <NEW> as Derek suggests and not preceding the entire declaration as 'auto' does now. I'll admit I prefer this idea to having nothing there, but I could live with either. Sean
Sep 04 2006
prev sibling next sibling parent reply Jeff <psychobrat gmail.com> writes:
+1 :)

I'm terrified of 'auto auto' making it into 1.0; it just -screams- "ugly 
and confusing" to me.
Sep 06 2006
parent Garett Bass <garettbass studiotekne.com> writes:
Agreed, this overload of the meaning of 'auto' has made me uncomfortable since
it was introduced.  It needlessly complicates things.

Jeff wrote:
 +1 :)
 
 I'm terrified of 'auto auto' making it into 1.0; it just -screams- "ugly 
 and confusing" to me.

Sep 06 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:
 BTW, I'm not wedded to 'local' but something, ... anything, that explicitly
 informs the reader that the object will be destroyed when it goes out of
 scope is needed. Leaving it out is not a good user interface.

Why? It's implicit in C style programming languages that things disappear when they go out of scope. It's the original meaning of 'auto' in C and C++, it's also the default behavior.
Sep 06 2006
parent Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 06 Sep 2006 21:07:15 -0700, Walter Bright wrote:

 Derek Parnell wrote:
 BTW, I'm not wedded to 'local' but something, ... anything, that explicitly
 informs the reader that the object will be destroyed when it goes out of
 scope is needed. Leaving it out is not a good user interface.

Why? It's implicit in C style programming languages that things disappear when they go out of scope. It's the original meaning of 'auto' in C and C++, it's also the default behavior.

(N.B: I'm talking about the proposed situation where the D 'auto' keyword is *not* used to implement RAII.) Because D doesn't work that way. Sometimes, even when the object goes out of scope, the object is not destroyed - that is, the dtor is not guaranteed to be called. However, if you use a 'auto' object the dtor is called. import std.stdio; class Foo { static int s_cnt; int m_cnt; char[] m_id; this(char[] id) { m_id = id.dup; s_cnt++; m_cnt = s_cnt; writefln(m_id," CTOR", m_cnt); } ~this() { writefln(m_id, " DTOR", m_cnt);} } void func(char[] id) { Foo a = new Foo(id); auto Foo b = new Foo(id); // the dtor for 'a' is not necessarily called on func exit. // the dtor for 'b' is always called on func exit. } void main() { func("A"); func("B"); func("C"); func("D"); } The output from this is ... A CTOR1 A CTOR2 A DTOR2 B CTOR3 B CTOR4 B DTOR4 C CTOR5 C CTOR6 C DTOR6 D CTOR7 D CTOR8 D DTOR8 D DTOR7 C DTOR5 B DTOR3 A DTOR1 which clearly shows that the currently 'auto' objects are destroyed on scope exit but non-auto ones are not. My earlier discussion was focused on replacing the 'auto' keyword for RAII with a more meaningful keyword, such as 'local'. All I was saying was that I don't care so much which new keyword is used to replace 'auto' so long as it gives a better clue to the reader that a variable so decorated *WILL* be destroyed at scope end, as will its referenced object if any. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 7/09/2006 2:38:38 PM
Sep 06 2006
prev sibling next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Jarrett Billingsley wrote:
 This is what I'm talking about:
 
 Foo f = Foo(); // RAII
 Foo g = new Foo(); // Normal
 
 Can we all discuss this?  I'm sorry, but that syntax is just too easy to 
 mess up / miss.  I'm surprised that you, someone who is very much against 
 "secret things happening" would be a proponent of this syntax.  It's just 
 too nonobvious.  (And as a minor point, this also makes it impossible to 
 make a static opCall with a class.)
 
 How about instead, we keep auto to mean a RAII reference, and we take the C# 
 route for type inference and come up with a "var" keyword which would be a 
 "type placeholder".  That is:
 
 var f = new Foo(); // Normal
 auto var g = new Foo(); // RAII
 
 And as you can see, this gets rid of thee "auto auto" problem.  Not to 
 mention it gets rid of the very common misunderstanding that currently, 
 "auto" is somehow used for type inference, when in fact it's simply the use 
 of a storage class without a type that invokes type inference.
 
 This, or maybe we could use a "stack" or "local" or "raii" keyword in place 
 of the "new":
 
 Foo f = stack Foo();
 Foo g = local Foo();
 Foo h = raii Foo();
 
 Something.  Anything would be better than the "new or nothing" syntax. 
 
 

I agree. It also makes sense to me to use various keywords to determine what kind of allocation is done: Foo a = new Foo(); // compiler optimized allocation Foo b = heap Foo(); // allocate on heap Foo c = stack Foo(); // allocate on stack Foo d = scope Foo(); // raii Also, it may be wise to make the keyword prefix the lvalue rather than be the allocator, for a reason I saw pointed out by Bruno Medeiros in a previous discussion: 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 ... so we'd have scope Foo f = new Foo(); and I don't know why anyone would want to, but someday you could scope Foo f = heap Foo();
Sep 04 2006
parent reply Brad Roberts <braddr puremagic.com> writes:
Chad J wrote:
 Jarrett Billingsley wrote:
 This is what I'm talking about:

 Foo f = Foo(); // RAII
 Foo g = new Foo(); // Normal

 Can we all discuss this?  I'm sorry, but that syntax is just too easy 
 to mess up / miss.  I'm surprised that you, someone who is very much 
 against "secret things happening" would be a proponent of this 
 syntax.  It's just too nonobvious.  (And as a minor point, this also 
 makes it impossible to make a static opCall with a class.)

 How about instead, we keep auto to mean a RAII reference, and we take 
 the C# route for type inference and come up with a "var" keyword which 
 would be a "type placeholder".  That is:

 var f = new Foo(); // Normal
 auto var g = new Foo(); // RAII

 And as you can see, this gets rid of thee "auto auto" problem.  Not to 
 mention it gets rid of the very common misunderstanding that 
 currently, "auto" is somehow used for type inference, when in fact 
 it's simply the use of a storage class without a type that invokes 
 type inference.

 This, or maybe we could use a "stack" or "local" or "raii" keyword in 
 place of the "new":

 Foo f = stack Foo();
 Foo g = local Foo();
 Foo h = raii Foo();

 Something.  Anything would be better than the "new or nothing" syntax.

I agree. It also makes sense to me to use various keywords to determine what kind of allocation is done: Foo a = new Foo(); // compiler optimized allocation Foo b = heap Foo(); // allocate on heap Foo c = stack Foo(); // allocate on stack Foo d = scope Foo(); // raii Also, it may be wise to make the keyword prefix the lvalue rather than be the allocator, for a reason I saw pointed out by Bruno Medeiros in a previous discussion: 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 ... so we'd have scope Foo f = new Foo(); and I don't know why anyone would want to, but someday you could scope Foo f = heap Foo();

Specifying storage mechanism seems like unnecessary compiler hamstringing. Specify behavior and give the compiler authors the freedom to detect and optimize the storage. See previous discussions on escape analysis. Ages ago it was realized in the C language and descendants that the 'register' keyword was pointless and, as far as I know, no compiler today obeys it. Let's not repeat that misfeature. Later, Brad
Sep 04 2006
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Brad Roberts wrote:
 Chad J wrote:
 
 Jarrett Billingsley wrote:

 This is what I'm talking about:

 Foo f = Foo(); // RAII
 Foo g = new Foo(); // Normal

 Can we all discuss this?  I'm sorry, but that syntax is just too easy 
 to mess up / miss.  I'm surprised that you, someone who is very much 
 against "secret things happening" would be a proponent of this 
 syntax.  It's just too nonobvious.  (And as a minor point, this also 
 makes it impossible to make a static opCall with a class.)

 How about instead, we keep auto to mean a RAII reference, and we take 
 the C# route for type inference and come up with a "var" keyword 
 which would be a "type placeholder".  That is:

 var f = new Foo(); // Normal
 auto var g = new Foo(); // RAII

 And as you can see, this gets rid of thee "auto auto" problem.  Not 
 to mention it gets rid of the very common misunderstanding that 
 currently, "auto" is somehow used for type inference, when in fact 
 it's simply the use of a storage class without a type that invokes 
 type inference.

 This, or maybe we could use a "stack" or "local" or "raii" keyword in 
 place of the "new":

 Foo f = stack Foo();
 Foo g = local Foo();
 Foo h = raii Foo();

 Something.  Anything would be better than the "new or nothing" syntax.

I agree. It also makes sense to me to use various keywords to determine what kind of allocation is done: Foo a = new Foo(); // compiler optimized allocation Foo b = heap Foo(); // allocate on heap Foo c = stack Foo(); // allocate on stack Foo d = scope Foo(); // raii Also, it may be wise to make the keyword prefix the lvalue rather than be the allocator, for a reason I saw pointed out by Bruno Medeiros in a previous discussion: 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 ... so we'd have scope Foo f = new Foo(); and I don't know why anyone would want to, but someday you could scope Foo f = heap Foo();


The following works right now, and does so just fine: Foo foo = SomeFactory.newFoo(...); scope(exit) delete foo; char[] a = read(filename); scope(exit) delete a; -- Chris Nicholson-Sauls
Sep 04 2006
parent reply Garett Bass <garettbass studiotekne.com> writes:
I wasn't aware of that, pretty cool!  In this case, perhaps do away with the
old local-scope meaning of 'auto' altogether.

Chris Nicholson-Sauls wrote:
 
 The following works right now, and does so just fine:
     Foo foo = SomeFactory.newFoo(...); scope(exit) delete foo;
     char[] a = read(filename); scope(exit) delete a;
 
 -- Chris Nicholson-Sauls

Sep 06 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
No.  The advantage of auto is that you can enforce this behaviour at the 
class declaration.
Example:

auto class Foo
{
   int member;
   this() {}
}

void main()
{
   auto Foo foo = new Foo(); // ok
   Foo bar = new Foo(); // error: reference to auto class must be auto
}

Of course, what Chris pointed out is cool from the standpoint that we 
could probably have the 'auto' keyword (or whatever may replace it) be 
in the allocator position without losing too much.

Garett Bass wrote:
 I wasn't aware of that, pretty cool!  In this case, perhaps do away with 
 the old local-scope meaning of 'auto' altogether.
 
 Chris Nicholson-Sauls wrote:
 
 The following works right now, and does so just fine:
     Foo foo = SomeFactory.newFoo(...); scope(exit) delete foo;
     char[] a = read(filename); scope(exit) delete a;

 -- Chris Nicholson-Sauls


Sep 06 2006
parent Sean Kelly <sean f4.ca> writes:
Chad J wrote:
 No.  The advantage of auto is that you can enforce this behaviour at the 
 class declaration.
 Example:
 
 auto class Foo
 {
   int member;
   this() {}
 }
 
 void main()
 {
   auto Foo foo = new Foo(); // ok
   Foo bar = new Foo(); // error: reference to auto class must be auto
 }

This is cool in theory but I have yet to actually use this feature. I simply don't see the point in re-using 'auto' in this way.
 Of course, what Chris pointed out is cool from the standpoint that we 
 could probably have the 'auto' keyword (or whatever may replace it) be 
 in the allocator position without losing too much.

If a keyword were retained to signify auto-destruction then I think it should be in place of 'new' and not attached to the variable itself. Reason being that it's the data that's going away, not whatever that variable happens to reference on scope end. Sean
Sep 06 2006
prev sibling next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Jarrett Billingsley wrote:
 This is what I'm talking about:
 
 Foo f = Foo(); // RAII
 Foo g = new Foo(); // Normal
 
 Can we all discuss this?  I'm sorry, but that syntax is just too easy to 
 mess up / miss.  I'm surprised that you, someone who is very much against 
 "secret things happening" would be a proponent of this syntax.  It's just 
 too nonobvious.  (And as a minor point, this also makes it impossible to 
 make a static opCall with a class.)
 
 How about instead, we keep auto to mean a RAII reference, and we take the C# 
 route for type inference and come up with a "var" keyword which would be a 
 "type placeholder".  That is:
 
 var f = new Foo(); // Normal
 auto var g = new Foo(); // RAII
 
 And as you can see, this gets rid of thee "auto auto" problem.  Not to 
 mention it gets rid of the very common misunderstanding that currently, 
 "auto" is somehow used for type inference, when in fact it's simply the use 
 of a storage class without a type that invokes type inference.
 
 This, or maybe we could use a "stack" or "local" or "raii" keyword in place 
 of the "new":
 
 Foo f = stack Foo();
 Foo g = local Foo();
 Foo h = raii Foo();
 
 Something.  Anything would be better than the "new or nothing" syntax. 
 
 

I despise writing "me too" posts, but in this case I just cannot avoid it. So... me too! I also find it intriguing that Phobos' RegExp module includes the following: # public static RegExp opCall(rchar[] pattern, rchar[] attributes = null) # { # return new RegExp(pattern, attributes); # } Yes in this case it is nothing but a wrapper around the constructor, and essentially useless so far as I can tell. However, the fact that Walter felt compelled to provide such a creature is telling. Personally I favor either 'local' or 'scope'/'scoped' as a new keyword for this purpose, and do believe as others that it belongs in 'new's current position. The option of 'scope'/'scoped' has the added benefit of consistancy with current keywords and usage. -- Chris Nicholson-Sauls
Sep 04 2006
prev sibling next sibling parent reply Robert Atkinson <Robert.Atkinson NO.gmail.com.SPAM> writes:
I'm a fan of the local keyword, or perhaps combining with the existing 
scope keywords as follows:

local:

local File file = new File(); // local RAII
local auto file = new File(); // local RAII + auto typing

or

scope(local):

scope(local) File file = new File();
scope(local) auto file = new File();

scope(local) is a little long for a single line, but it begins to look 
better if you have a group of RAII variables:

scope(local)
{
	File file;
	RecordSet rs;
	// etc
}


I believe that if we keep the auto/auto syntax, it will be a feature 
that everyone will love at first, but years from now it'll be the 
feature that we'll be cursing when we all have to maintain code. 
Scanning code quickly its hard to determine with the current auto/auto 
syntax if its RAII or auto typing.

Rob


Jarrett Billingsley wrote:
 This is what I'm talking about:
 
 Foo f = Foo(); // RAII
 Foo g = new Foo(); // Normal
 
 Can we all discuss this?  I'm sorry, but that syntax is just too easy to 
 mess up / miss.  I'm surprised that you, someone who is very much against 
 "secret things happening" would be a proponent of this syntax.  It's just 
 too nonobvious.  (And as a minor point, this also makes it impossible to 
 make a static opCall with a class.)
 
 How about instead, we keep auto to mean a RAII reference, and we take the C# 
 route for type inference and come up with a "var" keyword which would be a 
 "type placeholder".  That is:
 
 var f = new Foo(); // Normal
 auto var g = new Foo(); // RAII
 
 And as you can see, this gets rid of thee "auto auto" problem.  Not to 
 mention it gets rid of the very common misunderstanding that currently, 
 "auto" is somehow used for type inference, when in fact it's simply the use 
 of a storage class without a type that invokes type inference.
 
 This, or maybe we could use a "stack" or "local" or "raii" keyword in place 
 of the "new":
 
 Foo f = stack Foo();
 Foo g = local Foo();
 Foo h = raii Foo();
 
 Something.  Anything would be better than the "new or nothing" syntax. 
 
 

Sep 05 2006
next sibling parent Kristian <kjkilpi gmail.com> writes:
On Tue, 05 Sep 2006 19:30:30 +0300, Robert Atkinson  =

<Robert.Atkinson NO.gmail.com.SPAM> wrote:
[snip]
 I believe that if we keep the auto/auto syntax, it will be a feature  =

 that everyone will love at first, but years from now it'll be the  =

 feature that we'll be cursing when we all have to maintain code.  =

 Scanning code quickly its hard to determine with the current auto/auto=

 syntax if its RAII or auto typing.

 Rob

Well, I got confused right away (when I discovered D). ;) (And hence nev= er = liked the auto/auto syntax.) I think it really should be changed.
 Jarrett Billingsley wrote:
 This is what I'm talking about:
  Foo f =3D Foo(); // RAII
 Foo g =3D new Foo(); // Normal
  Can we all discuss this?  I'm sorry, but that syntax is just too eas=


 to mess up / miss.  I'm surprised that you, someone who is very much =


 against "secret things happening" would be a proponent of this syntax=


 It's just too nonobvious.  (And as a minor point, this also makes it =


 impossible to make a static opCall with a class.)
  How about instead, we keep auto to mean a RAII reference, and we tak=


 the C# route for type inference and come up with a "var" keyword whic=


 would be a "type placeholder".  That is:
  var f =3D new Foo(); // Normal
 auto var g =3D new Foo(); // RAII
  And as you can see, this gets rid of thee "auto auto" problem.  Not =


 mention it gets rid of the very common misunderstanding that currentl=


 "auto" is somehow used for type inference, when in fact it's simply t=


 use of a storage class without a type that invokes type inference.
  This, or maybe we could use a "stack" or "local" or "raii" keyword i=


 place of the "new":
  Foo f =3D stack Foo();
 Foo g =3D local Foo();
 Foo h =3D raii Foo();
  Something.  Anything would be better than the "new or nothing" synta=



Sep 05 2006
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Robert Atkinson wrote:
 I believe that if we keep the auto/auto syntax, it will be a feature 
 that everyone will love at first, but years from now it'll be the 
 feature that we'll be cursing when we all have to maintain code. 
 Scanning code quickly its hard to determine with the current auto/auto 
 syntax if its RAII or auto typing.

Auto/auto will be ridiculed by those never aiming to switch to D. It will cause havoc when teaching the language. And it will embarrass each of us later when folks ask "weren't you in the D community? How come you didn't get rid of that thing already pre 1.0??" Having things that look alike be different (and while I'm at it, also things that look different be the same), is something that belongs to wicked computer games, or stupid job admission tests. Distinct concepts have to have distinct names. Clarity is the word.
Sep 06 2006
prev sibling next sibling parent reply Garett Bass <garettbass studiotekne.com> writes:
I'd like to note some problems that all of these approaches face.

Jarrett Billingsley wrote:
 
 Foo f = stack Foo();

Jarrett's proposed 'stack' allocation specifier is interesting in that it seems to indicate that the object currently referenced by f will be deleted even if a later line of code does something ugly like this: f = stack Foo(); // assign a different Foo to f Now both Foo objects will be *deallocated* as the stack unwinds, but it is not clear whether the destructor can be called on the unreferenced Foo, unless it is called during the reassignment process. Alternatively, either of these current implementations happily leaves one Foo object dangling on the heap: auto Foo g = new Foo(); g = new Foo(); // drops reference to original Foo Foo g = new Foo(); scope(exit) delete g; g = new Foo(); // drops reference to original Foo How does the GC maintain these dropped references? This seems like an easy bug to insert, and potentially a difficult one to find. It is unfortunate that true stack object instances do not exist in D. The 'stack' syntax defies D's current heap-only object allocation philosophy. Another advantage of C++ style stack object instances is the ability to overload the assignment operator, which allows an object instance to be treated as a built-in type. You can't do this in D because it would alias your ability to reassign the object reference to another object. C++ has no problem implementing real and imaginary numbers as classes, they need not be built-in types since their instances can be treated as such syntactically. I don't understand why modern high-level languages are so quick to discard (or bias against) the pointer. The distinction between object references/pointers and object instances is very valuable in C++. It can be nice to know that no other code is going to reassign another object to your variable. Pissing in the wind, Garett
Sep 06 2006
parent Kristian <kjkilpi gmail.com> writes:
On Thu, 07 Sep 2006 02:44:43 +0300, Garett Bass  
<garettbass studiotekne.com> wrote:
[snip]
 It is unfortunate that true stack object instances do not exist in D.   
 The 'stack' syntax defies D's current heap-only object allocation  
 philosophy.

 Another advantage of C++ style stack object instances is the ability to  
 overload the assignment operator, which allows an object instance to be  
 treated as a built-in type.  You can't do this in D because it would  
 alias your ability to reassign the object reference to another object.   
 C++ has no problem implementing real and imaginary numbers as classes,  
 they need not be built-in types since their instances can be treated as  
 such syntactically.

 I don't understand why modern high-level languages are so quick to  
 discard (or bias against) the pointer.  The distinction between object  
 references/pointers and object instances is very valuable in C++.  It  
 can be nice to know that no other code is going to reassign another  
 object to your variable.

 Pissing in the wind,
 Garett

Now I know why D feels a bit strange at time to time. I wasn't fully aware of it until Garett pointed it out. And that's unability to create build-in types with classes. :| I'm used to have my objects 'moduled', i.e. assigning X to Y and then changing Y won't change X. And there is no 'const' type... Time will tell how many errors I will make when handling my objects around... until I fully grab the concect of using references/pointers only. Hmm, it's also 'interesting' to see how much dupping I will need. But dupping doesn't create deep copy, erh... Should there be a 'physical' object instance class in D after all?
Sep 07 2006
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
I hate to dredge up an old post, but I was just thinking about this and 
thought I'd point out one thing to anyone listening:

RAII stands for Resource Allocation Is Initialization.  You can do RAII 
without automatically-deleted classes, it's just difficult.  For this 
reason, a keyword 'raii' would be inappropriate - what's being described 
is NOT RAII, it's just an incidental change that makes RAII more useful. 
  RDID (Resource Deallocation Is Destruction) is closer to what's being 
described, but still not spot-on: that has to do with the class 
definition, not the actual use of the class.  What's being described is 
simply an object associated with a scope.  In short: the changes 
described have nothing to do with RAII, they just make it more useful, 
so having a keyword 'raii' is nonsense.

If I see a keyword 'raii' meaning anything like this at any point in the 
future, I'll be crying myself to sleep that night :P

Just my 2

  - Gregor Richards
Sep 29 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Gregor Richards wrote:
 I hate to dredge up an old post, but I was just thinking about this and 
 thought I'd point out one thing to anyone listening:
 
 RAII stands for Resource Allocation Is Initialization.  You can do RAII 
 without automatically-deleted classes, it's just difficult.  For this 
 reason, a keyword 'raii' would be inappropriate - what's being described 
 is NOT RAII, it's just an incidental change that makes RAII more useful. 
  RDID (Resource Deallocation Is Destruction) is closer to what's being 
 described, but still not spot-on: that has to do with the class 
 definition, not the actual use of the class.  What's being described is 
 simply an object associated with a scope.  In short: the changes 
 described have nothing to do with RAII, they just make it more useful, 
 so having a keyword 'raii' is nonsense.
 
 If I see a keyword 'raii' meaning anything like this at any point in the 
 future, I'll be crying myself to sleep that night :P

If you get sleepless you might want to search the D newsgroup archives here on RAII. I promise you you'll be both crying and laughing the rest of the night. What got beaten to death were: the meaning of the acronym, various suggestions to replace it, the entire subject, the guy who's originally introduced the acronym, and half of the participants' keyboards. ;-) To comfort: you're not alone with your feeling.
Sep 29 2006