In article <djnghp$13ob$1@digitaldaemon.com>, Hauke Duden says...
>
>Walter Bright wrote:
>> Then, an RAII class object would be:
>> 
>>     auto c = classname(arguments);
>> 
>> and a non-RAII class object would be:
>> 
>>     auto c = new classname(arguments);
>
>Are you serious? This would make code very unreadable. Having keywords with multiple meanings is bad enough, but when the context looks as similar as in this case then things will get confusing very quickly.

I think Walter's example is of an auto typed class declaration.  You would also be able to instantiate a class like so:

classname c = classname(arguments);
classname c = new classname(arguments);

At the same time, the old RAII meaning of auto would be deprecated, as it's no longer needed if you can allocate classes on the stack.

>IMHO the non-RAII keyword should be something different. I think many alternatives have already been proposed, but I'd like to add one. Not sure what this would mean for parsability, but I like how this looks:
>
>... c = new classname(arguments);
>
>I.e. a new "..." keyword that represents an inferred type. Looks as if something was left out, which is exactly how it is.

I'm not sure I like it--it reminds me too much of implicitly declared variables in other languages.  It could also lead to subtle errors:

int myValue;
myvalue = 5;

With a token like 'auto' the programmer is able to explicitly declare which expressions are declarations.


Sean

"John C" <johnch_atms@hotmail.com> wrote in message news:djnapn$d2b$1@digitaldaemon.com...
> Superb. By introducing local type inference now, D is ahead of the competition in this respect. C# won't get it until version 3, C++ for a
long
> while yet, and Java probably never.
>
> Coincidentally (or maybe not), "auto" also happens to be the proposed C++
> syntax.

It's auto for the same reason, "auto" is an old C keyword used for local stack variables, and this presses it into service.

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:djnhiv$1833$1@digitaldaemon.com...
> I just realized that maybe I misunderstood your plans. Do you mean that "auto" will only be used to represent a type and will not be directly connected to RAII anymore? I.e. would I also be able to create a RAII object like this?
>
> classname c = classname(arguments)

Yes.

> In that case it would be easier to understand the concepts. However, readability would still suffer because
>
> auto c = classname(arguments);
>
> and
>
> auto c = new classname(arguments);
>
> look so similar. It would be really nice if the lines would look more different because the automatic destruction of c is such an important fact to realize.

I think it makes logical sense, one expects new to allocate on the heap, and non-new to allocate on the stack.

> What about a C++ style syntax plus a keyword to make parsing easier?
>
> local classname c(arguments)

The "function style" constructors in C++ declarations cause a lot of ambiguity problems. Parsing of the auto c = classname(args) is easy. The work comes in keeping careful track of when to insert the destructors.

"Vathix" <chris@dprogramming.com> wrote in message news:op.sy8x7py7l2lsvj@esi...
> I like it. Only problem I can think of is conflicts if the class has a static opCall. Perhaps classes should not have them

I'm hard pressed to see the point of them for classes anyway.

> (but they're very
> handy for structs/unions). This extra code in the compiler to support it
> could possibly be hacked in by adding an internal, implicit static opCall
> to all classes, which are translated to RAII constructors when invoked
>  from an initializer ;)

There's more work to get all the details ironed out, but that is where I want to go. It's needed because there are a certain class of problems D doesn't work well without.

In article <djo5n4$2cqp$1@digitaldaemon.com>, Sean Kelly says...
>
>classname c = classname(arguments);
>classname c = new classname(arguments);

Oops, I meant:

classname c = classname(arguments);
classname* c = new classname(arguments);

What would be ideal is if this syntax applied to all D types:

int x = int(5);
int* x = new int(5);

etc.  This makes instantiation easier to accomplish in template code as the syntax is consistent.  I'm not certain whether the ambiguity with opCall will be a problem however, as it's essentially a matter of overload resolution.  So long as static opCall functions and class ctors don't have the same parameter list I don't think the compiler will complain.


Sean

In article <djodvq$2nvh$2@digitaldaemon.com>, Walter Bright says...
>
>
>"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message
>>
>> What about a C++ style syntax plus a keyword to make parsing easier?
>>
>> local classname c(arguments)
>
>The "function style" constructors in C++ declarations cause a lot of ambiguity problems. Parsing of the auto c = classname(args) is easy. The work comes in keeping careful track of when to insert the destructors.

I very much agree.  Unless function prototypes become illegal in D I would very much prefer to use a non-ambiguous class construction syntax.  The C++ method can cause all sorts of subtle errors, and I've yet to meet a programmer who routinely constructs classes in a way that prevents them:

MyClass c( (p1), p2, p3 );

The above doesn't seem natural and looks a bit odd.  I also don't like that C++ baically offers two different ways to construct types:

T t(val);
T t = T(val);

While the optimizer can make these effectively equivalent, the rules surrounding the need for a copy ctor and assignment operator in C++ are not particularly intuitive, and a lot of that has to do with the need to support both construction formats.


Sean

In article <djodvq$2nvh$3@digitaldaemon.com>, Walter Bright says...
>
>There's more work to get all the details ironed out, but that is where I want to go. It's needed because there are a certain class of problems D doesn't work well without.

I'm glad to hear it :)  This is the only real syntax-level issue I have with D, and it's a relief to know that it will be addressed at some point.


Sean

pragma wrote:
> In article <djjpa0$1o9n$2@digitaldaemon.com>, Walter Bright says...
>> A couple of oft-requested features.
>>
>> http://www.digitalmars.com/d/changelog.html
> 
> Walter,
> I think others have brought this up, but there's a problem with overloading the
> use of 'auto' in this way.  If one wants to have both RAII *and* auto-type
> capabilities in the same statement, it can't be done since they both use the
> same keyword.
<snip>

You've got me wondering what practical use this auto-type facility has.  Just syntactic sugar for

    typeof(4u) y = 4u;

?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

"Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:djnlj6$1nbv$1@digitaldaemon.com...
> But I must say I too don't like having auto (type) share the same name as the unrelated (RAII) auto. Not only it has now that pratical problem of not being able to declare an "auto auto" object, but conceptually as well I don't think it's good to have two keywords with the same name who do quite different things. (remeber C's static ... ugh :P )

But I think it is completely related! All 'auto' declarations will be destroyed when they go out of scope. Remember that class declarations only give references to class objects, not class objects themselves. So, class(args) creates a stack class object, which is destroyed when it goes out of scope. new class(args) creates one on the heap, which is not.

"pragma" <pragma_member@pathlink.com> wrote in message news:djo2np$2995$1@digitaldaemon.com...
> I think others have brought this up, but there's a problem with
overloading the
> use of 'auto' in this way.  If one wants to have both RAII *and* auto-type capabilities in the same statement, it can't be done since they both use
the
> same keyword.

No, there isn't a conflict. Auto *always* makes it RAII. The initializer is another matter, though. If it's 'new', it's not RAII, if it's not 'new', it is not. There is no need at all for heap allocated objects to be RAII.

> Also, others have mentioned a possible ambiguity with "static opCall()"
and your
> proposal for stack-allocation.

I know, that has to be worked out.

> What are your thoughts on using a keyword in
> place of 'new' to signify stack-allocation?

I don't believe it's necessary.