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

<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

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

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 and  very little C#.
>>   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.

>>  Now, take a Java/C# programmer, their first program with classes 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 the  Java/C# programmer will need to ask the C++ programmer what the 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 course,  if you're a Java/C# programmer you have to 'learn' what the 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.

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

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
"var" is one character shorter. I also liked that it was the same as C#
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

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

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

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

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 context with the example of the C++ and Java/C# programmers).

I was attempting to compare the 2 proposals:
 - absence of 'new'
 - use of keyword 'scope' or 'local' or <insert favourite keyword>

by describing how a programmer from either the C++ or Java/C# world might 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 and does not hurt Java/C# programmer any more than having to learn and use a new keyword (as it's essentially the same thing)

Regan