On Tue, 25 Oct 2005 22:19:25 -0400, Carlos Santander <csantander619@gmail.com> wrote:

> Walter Bright escribió:
>> A couple of oft-requested features.
>>  http://www.digitalmars.com/d/changelog.html
>>
>
> I really like the auto type declaration, but I'd like to suggest something slightly related: can't static strings be of type char[] instead of static char[length]? The problem is that this doesn't work:
>
> auto str = "hi";
> str = "hello";
>

auto str = "hi"[];
str = "hello";

"Dave" <Dave_member@pathlink.com> wrote in message news:djmm80$1sm8$1@digitaldaemon.com...
> Hot damn!

It's still a bit low down on the priority list, though.

"Vathix" <chris@dprogramming.com> wrote in message news:op.sy8mfjbxl2lsvj@esi...
> On Tue, 25 Oct 2005 22:19:25 -0400, Carlos Santander <csantander619@gmail.com> wrote:
> > I really like the auto type declaration, but I'd like to suggest something slightly related: can't static strings be of type char[] instead of static char[length]? The problem is that this doesn't work:
> >
> > auto str = "hi";
> > str = "hello";
>
> auto str = "hi"[];
> str = "hello";

I had missed that. Thanks for pointing it out.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:djjpa0$1o9n$2@digitaldaemon.com...
>A couple of oft-requested features.
>
> http://www.digitalmars.com/d/changelog.html
>
>

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.

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.

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.


Hauke

Hauke Duden wrote:
> 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.
> 
> IMHO the non-RAII keyword should be something different.

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)

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.

What about a C++ style syntax plus a keyword to make parsing easier?

local classname c(arguments)


Hauke

On Tue, 25 Oct 2005 19:15:12 -0400, Walter Bright <newshound@digitalmars.com> wrote:

>
> "Sai" <Sai_member@pathlink.com> wrote in message
> news:djm1oj$p58$1@digitaldaemon.com...
>> Is the answer for it is to use a new keyword or to make the compiler
> smarter ?
>
> It's implementing class objects on the stack with the:
>     classname(constructor arguments)
> syntax. Then, an RAII class object would be:
>
>     auto c = classname(arguments);
>
> and a non-RAII class object would be:
>
>     auto c = new classname(arguments);
>
> and the old RAII syntax would be supported as:
>
>     auto classname c = new classname(arguments);
>
> and eventually deprecated.

I like it. Only problem I can think of is conflicts if the class has a static opCall. Perhaps classes should not have them (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 ;)

Walter Bright wrote:
> A couple of oft-requested features.
> 
> http://www.digitalmars.com/d/changelog.html

Now that you're working on the compiler once again, is there any chance of an answer about these any time soon?

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/28426
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/28449

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.

Walter Bright wrote:
> "Sai" <Sai_member@pathlink.com> wrote in message
> news:djm1oj$p58$1@digitaldaemon.com...
> 
>>Is the answer for it is to use a new keyword or to make the compiler
> 
> smarter ?
> 
> It's implementing class objects on the stack with the:
>     classname(constructor arguments)
> syntax. Then, an RAII class object would be:
> 
>     auto c = classname(arguments);
> 
> and a non-RAII class object would be:
> 
>     auto c = new classname(arguments);
> 
> and the old RAII syntax would be supported as:
> 
>     auto classname c = new classname(arguments);
> 
> and eventually deprecated.
> 
> 
First of all, kudos on this great feature!

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 )

Now, as for possible alternative solutions, I don't like that proposed one either. Doesn't read that well, and it still has the homonymous keywords.

How about having autoraii be just an alternative to new. Something like:
  Foo foo = autonew Foo(arguments);
possibly with a different shorter name than autonew, like anew, or snew. And an autotype autoraii object would be:
  auto foo = anew Foo(arguments);

Incidently, and I mean incidently, it would allow anonymous autoraii objects, and consequently would allow easier work with blocks/scopes. Something like:

                                // prints:
{ anew HtmlHtml();              // <html>
  { anew HtmlHead();            //   <head>
    HtmlTitle("History");       //     <title>History</title>
  }                             //   </head>
  { anew HtmlBody();            //   <body>
    HtmlComment("HI");          //     <!-- HI -->
    HtmlHeader("Header");       //     <h1>Header</h1>
    { anew HtmlParagraph();     //     <p>
      HtmlText("paragraph");    //       paragraph
    }                           //     </p>
  }                             //   </body>
}                               // </html>

Interesting at least, but this whole issue needs to be thought about more.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

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.

Might I propose moving the RAII aspect of auto out to a new keyword?  How about "raii"?

// code listed including your proposal for stack-allocation, for completeness

auto a = new classname();      // auto-type, heap alloc
auto b = classname();          // auto-type, stack alloc
raii c = new classname();      // RAII, heap alloc
raii d = classname();          // RAII, stack alloc
auto raii e = new classname(); // auto-type, RAII, heap alloc
auto raii f = classname();     // auto-type, RAII, stack alloc

Also, others have mentioned a possible ambiguity with "static opCall()" and your proposal for stack-allocation.  What are your thoughts on using a keyword in place of 'new' to signify stack-allocation?

- EricAnderton at yahoo