www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Thoughts about the D 1.0 release

reply Helmut Leitner <leitner hls.via.at> writes:
As so many have written about 1.0 I feel the urgent need to add my $0.02

First of all I do not care about when D 1.0 will be released. This is
totally unimportant to me (within a plausible time range of 3-12 months
from now, of course). The only really important thing is:

  * post-1.00-changes to the compiler must NOT break 1.00 code

I just revived some 0.79 test code and I had to insert a lot of casts
and change all op-overloading methods. Also function parameter type 
matching seems to have changed, for float expressions won't match with
a long parameter function signature anymore (more casts!). 

While these changes may make sense it was frustrating work for nothing. 
It is acceptable to me in 0.xxx but would not be going from 1.00 to 1.01

I know at least 3 contributors who struggled through the undig project to
bring it up to date with dmd 0.1xx. After removing formal errors some
examples still won't work (as they did some time ago; problems in 
Windows API interfacing?). 

The bottom line is: whatever you wish for 1.00 it will be of no significance 
if the code written for dmd 1.00 will not compile and execute flawlessly in the 
dmd 3.27 of 2010. So its not so much about what features to include now,
but about when to restrict the headroom for fundamental changes.

BTW my best guess is that 0.127 will be 1.00
I'm thinking about a website where you can place your bets!  :-)

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Sep 06 2004
next sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <413C702D.9F2A116 hls.via.at>, Helmut Leitner says...

As so many have written about 1.0 I feel the urgent need to add my $0.02

First of all I do not care about when D 1.0 will be released. This is
totally unimportant to me (within a plausible time range of 3-12 months
from now, of course). The only really important thing is:

  * post-1.00-changes to the compiler must NOT break 1.00 code

I just revived some 0.79 test code and I had to insert a lot of casts
and change all op-overloading methods. Also function parameter type 
matching seems to have changed, for float expressions won't match with
a long parameter function signature anymore (more casts!). 

While these changes may make sense it was frustrating work for nothing. 
It is acceptable to me in 0.xxx but would not be going from 1.00 to 1.01

I know at least 3 contributors who struggled through the undig project to
bring it up to date with dmd 0.1xx. After removing formal errors some
examples still won't work (as they did some time ago; problems in 
Windows API interfacing?). 

The bottom line is: whatever you wish for 1.00 it will be of no significance 
if the code written for dmd 1.00 will not compile and execute flawlessly in the 
dmd 3.27 of 2010. So its not so much about what features to include now,
but about when to restrict the headroom for fundamental changes.


I agree that v1.0 should not be released until the fundemental issues are
settled.

Not to minimize the potential for the impact of language changes to legacy code,
but I think some of these concerns post-v1.0 are taken into account with
features of the language (ie: Versioning) and DMD reference compiler (ie: -d
switch).

I was curious about the progress of D compared to other languages and it seems
that it is actually coming along very well compared to Java, C and C++. 

http://www.ils.unc.edu/blaze/java/javahist.html
http://www.intap.net/~drw/cpp/cpp01_03.htm

Especially considering /one person/ is doing the compiler, much of the library
and also did the bulk of the language design. If I remember correctly (and
someone please correct me if I'm wrong), but the design didn't start until late
'99 and the implementation in earnest probably late 2001/early 2002.

I know there are concerns about the state of the library too, but all-in-all I
think that is doing pretty well at this stage (a big THANKS to those
developers).

I'm impatient for the release - I want to get on with turning out production
code with it! But I can wait a few months to let things stabilize with the
language and compiler and for the libraries to mature too.


BTW my best guess is that 0.127 will be 1.00
I'm thinking about a website where you can place your bets!  :-)


IMO, one thing that doesn't get a whole lot of mention in these groups is
performance and maybe rightly so for the time being, as long as it is given some
attention before the release of v1.0.

Although I personally might be guilty of putting /too/ much stock in screaming
performance, I think Java and C++ history is on the side of spending at least a
little time - once the compiler and language is stable - on optimizing things
before v1.0 is released. I think waiting until 0.130 <g> or so for that would do
D users and the language (in terms of acceptance) a lot of good. Once a language
gets tagged with performance issue, it seems about half the potential converts
walk away and don't look back for a couple of years.

I almost hate to mention it at this point, but the AMD64 stuff seems to be
really taking off (I'm actually using it everyday) and some code gen. support
for that should be in v1.1 or maybe v1.01 <g>. Good support for that right out
of the gate w/ v1.0 may be a big differentiator for the language and DMD
compiler too, but perhaps that is asking way to much of Walter..

- Dave


-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Sep 06 2004
next sibling parent reply "antiAlias" <fu bar.com> writes:
Good points. Regarding performance:

Support for AMD64 would likely boost performance right away ~ due to the
additional registers available. D is actually pretty fast right now,
although there are specific areas that are lacking (vectorized array
processing; the ever-present and sometimes long-winded array initialization;
etc).

On the other hand, with careful design you can craft D code that's quite a
bit faster than the average-bear. For example, array slicing can speed up a
text-oriented process significantly (it's much easier to do this in D than
any other language I'm familiar with),  so it really depends upon the task
at hand.

Would like to see it get better though! I recall that Valgrind showed D to
have almost twice as many load/store ops as an equivalent C implementation
for some test or other. While that's not indicative of a non-performant
language, it does suggest a predilection for register spills (or something).
Perhaps array initialization caused all those additional memory references
<g>


"Dave" <Dave_member pathlink.com> wrote in message
news:chi0i0$1fb5$1 digitaldaemon.com...
In article <413C702D.9F2A116 hls.via.at>, Helmut Leitner says...

As so many have written about 1.0 I feel the urgent need to add my $0.02

First of all I do not care about when D 1.0 will be released. This is
totally unimportant to me (within a plausible time range of 3-12 months
from now, of course). The only really important thing is:

  * post-1.00-changes to the compiler must NOT break 1.00 code

I just revived some 0.79 test code and I had to insert a lot of casts
and change all op-overloading methods. Also function parameter type
matching seems to have changed, for float expressions won't match with
a long parameter function signature anymore (more casts!).

While these changes may make sense it was frustrating work for nothing.
It is acceptable to me in 0.xxx but would not be going from 1.00 to 1.01

I know at least 3 contributors who struggled through the undig project to
bring it up to date with dmd 0.1xx. After removing formal errors some
examples still won't work (as they did some time ago; problems in
Windows API interfacing?).

The bottom line is: whatever you wish for 1.00 it will be of no


significance

if the code written for dmd 1.00 will not compile and execute flawlessly in


the

dmd 3.27 of 2010. So its not so much about what features to include now,
but about when to restrict the headroom for fundamental changes.


I agree that v1.0 should not be released until the fundemental issues are
settled.

Not to minimize the potential for the impact of language changes to legacy
code,
but I think some of these concerns post-v1.0 are taken into account with
features of the language (ie: Versioning) and DMD reference compiler (ie: -d
switch).

I was curious about the progress of D compared to other languages and it
seems
that it is actually coming along very well compared to Java, C and C++.

http://www.ils.unc.edu/blaze/java/javahist.html
http://www.intap.net/~drw/cpp/cpp01_03.htm

Especially considering /one person/ is doing the compiler, much of the
library
and also did the bulk of the language design. If I remember correctly (and
someone please correct me if I'm wrong), but the design didn't start until
late
'99 and the implementation in earnest probably late 2001/early 2002.

I know there are concerns about the state of the library too, but all-in-all
I
think that is doing pretty well at this stage (a big THANKS to those
developers).

I'm impatient for the release - I want to get on with turning out production
code with it! But I can wait a few months to let things stabilize with the
language and compiler and for the libraries to mature too.


BTW my best guess is that 0.127 will be 1.00
I'm thinking about a website where you can place your bets!  :-)


IMO, one thing that doesn't get a whole lot of mention in these groups is
performance and maybe rightly so for the time being, as long as it is given
some
attention before the release of v1.0.

Although I personally might be guilty of putting /too/ much stock in
screaming
performance, I think Java and C++ history is on the side of spending at
least a
little time - once the compiler and language is stable - on optimizing
things
before v1.0 is released. I think waiting until 0.130 <g> or so for that
would do
D users and the language (in terms of acceptance) a lot of good. Once a
language
gets tagged with performance issue, it seems about half the potential
converts
walk away and don't look back for a couple of years.

I almost hate to mention it at this point, but the AMD64 stuff seems to be
really taking off (I'm actually using it everyday) and some code gen.
support
for that should be in v1.1 or maybe v1.01 <g>. Good support for that right
out
of the gate w/ v1.0 may be a big differentiator for the language and DMD
compiler too, but perhaps that is asking way to much of Walter..

- Dave


--
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Sep 06 2004
parent reply Helmut Leitner <leitner hls.via.at> writes:
antiAlias wrote:

 
 I agree that v1.0 should not be released until the fundemental issues are
 settled.
 


That was not my point - D may develop any way...
... BUT developments must not break 1.00 code.

Imagine for example an introductory book containing examples 
that won't run half a year later - a desaster for the author
of the book, the frustrated readers and the language.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Sep 07 2004
next sibling parent reply "antiAlias" <fu bar.com> writes:
Uhhh; excuse me? Dave said that, Helmut ~ not I

:-)


"Helmut Leitner" <leitner hls.via.at> wrote in message
news:413D7D1C.EF07F49E hls.via.at...


antiAlias wrote:

 I agree that v1.0 should not be released until the fundemental issues are
 settled.


That was not my point - D may develop any way...
... BUT developments must not break 1.00 code.

Imagine for example an introductory book containing examples
that won't run half a year later - a desaster for the author
of the book, the frustrated readers and the language.

--
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Sep 07 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
antiAlias wrote:

 Uhhh; excuse me? Dave said that, Helmut ~ not I
 
 :-)


I'm sure it was an accident. ;)

You might be able to adjust your newsreader settings so that the 
"quote-markers" are added to each line when you reply (like it does for 
pretty much everyone else). When the extra ">" symbols are missing, 
quoting the quoter can be especially misleading.


 
 
 "Helmut Leitner" <leitner hls.via.at> wrote in message
 news:413D7D1C.EF07F49E hls.via.at...
 
 
 antiAlias wrote:
 

I agree that v1.0 should not be released until the fundemental issues are
settled.


 
 
 That was not my point - D may develop any way...
 ... BUT developments must not break 1.00 code.
 
 Imagine for example an introductory book containing examples
 that won't run half a year later - a desaster for the author
 of the book, the frustrated readers and the language.
 
 --
 Helmut Leitner    leitner hls.via.at
 Graz, Austria   www.hls-software.com



-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Sep 07 2004
parent "antiAlias" <fu bar.com> writes:
"J C Calvarese" <jcc7 cox.net>
| antiAlias wrote:
| > Uhhh; excuse me? Dave said that, Helmut ~ not I
| >
| > :-)
|
| I'm sure it was an accident. ;)
|
| You might be able to adjust your newsreader settings so that the
| "quote-markers" are added to each line when you reply (like it does for
| pretty much everyone else). When the extra ">" symbols are missing,
| quoting the quoter can be especially misleading.

Thanks!
Sep 08 2004
prev sibling next sibling parent Joey Peters <Joey_member pathlink.com> writes:
In article <chkmi2$2kke$1 digitaldaemon.com>, Dave says...

In article <chkkpm$2jn9$1 digitaldaemon.com>, Dave says...

In article <413D7D1C.EF07F49E hls.via.at>, Helmut Leitner says...

That was not my point - D may develop any way...
... BUT developments must not break 1.00 code.

Imagine for example an introductory book containing examples 
that won't run half a year later - a desaster for the author
of the book, the frustrated readers and the language.


Hardily agree.

- Dave


Uff da, that should be 'heartily agree' ;)

- Dave


Is there an iso for D? If in the near future there would be then I guess it
would be safe to start writing books. Huray for books.
Sep 07 2004
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <413D7D1C.EF07F49E hls.via.at>, Helmut Leitner says...

antiAlias wrote:

 
 I agree that v1.0 should not be released until the fundemental issues are
 settled.
 


That was not my point - D may develop any way...
... BUT developments must not break 1.00 code.

Imagine for example an introductory book containing examples 
that won't run half a year later - a desaster for the author
of the book, the frustrated readers and the language.


Sounds like what happened to Java ;)


Sean
Sep 07 2004
parent "Phill" <phill pacific.net.au> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:chkqho$2n80$1 digitaldaemon.com...

 In article <413D7D1C.EF07F49E hls.via.at>, Helmut Leitner says...

antiAlias wrote:

 I agree that v1.0 should not be released until the fundemental issues






are

 settled.


That was not my point - D may develop any way...
... BUT developments must not break 1.00 code.

Imagine for example an introductory book containing examples
that won't run half a year later - a desaster for the author
of the book, the frustrated readers and the language.


 Sounds like what happened to Java ;)


If its the same as what happend to Java, then D
is in for a great future. Time(and plenty of it)will tell, I guess.

Phill.
Sep 08 2004
prev sibling next sibling parent "Walter" <newshound digitalmars.com> writes:
"Helmut Leitner" <leitner hls.via.at> wrote in message
news:413D7D1C.EF07F49E hls.via.at...

 antiAlias wrote:

 I agree that v1.0 should not be released until the fundemental issues




are

 settled.


 That was not my point - D may develop any way...
 ... BUT developments must not break 1.00 code.

 Imagine for example an introductory book containing examples
 that won't run half a year later - a desaster for the author
 of the book, the frustrated readers and the language.


New standards always break existing code - happened with both C standards,
and with C++. The argument to change something that does break existing
code, however, needs to be very compelling after 1.0. Also, post-1.0
compilers will need to have a 1.0 compatibility mode as much as practical.
Sep 07 2004
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Helmut Leitner" <leitner hls.via.at> wrote in message
news:413D7D1C.EF07F49E hls.via.at...

 antiAlias wrote:

 I agree that v1.0 should not be released until the fundemental issues are
 settled.


 That was not my point - D may develop any way...
 ... BUT developments must not break 1.00 code.

 Imagine for example an introductory book containing examples
 that won't run half a year later - a desaster for the author
 of the book, the frustrated readers and the language.


Indeed!
Sep 07 2004
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
I was curious about the progress of D compared to other languages and it seems
that it is actually coming along very well compared to Java, C and C++. 

http://www.ils.unc.edu/blaze/java/javahist.html
http://www.intap.net/~drw/cpp/cpp01_03.htm

Especially considering /one person/ is doing the compiler, much of the library
and also did the bulk of the language design. If I remember correctly (and
someone please correct me if I'm wrong), but the design didn't start until late
'99 and the implementation in earnest probably late 2001/early 2002.


Yes, but D didn't invent too much new stuff. It's just a mix of several
languages with VERY few own ideas.
Sep 06 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:chifup$1m9j$1 digitaldaemon.com...

I was curious about the progress of D compared to other languages and it




seems

that it is actually coming along very well compared to Java, C and C++.

http://www.ils.unc.edu/blaze/java/javahist.html
http://www.intap.net/~drw/cpp/cpp01_03.htm

Especially considering /one person/ is doing the compiler, much of the




library

and also did the bulk of the language design. If I remember correctly




(and

someone please correct me if I'm wrong), but the design didn't start




until late

'99 and the implementation in earnest probably late 2001/early 2002.


 Yes, but D didn't invent too much new stuff. It's just a mix of several
 languages with VERY few own ideas.


D does have some significant novel ideas, like its approach to utf strings,
how foreach works, mixins, arrays, etc. But it isn't intended to be loaded
with novel ideas, it's a refactoring and refinement of existing and proven
ideas. D is an engineering job, not an academic research project.
Sep 06 2004
next sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
D does have some significant novel ideas, like its approach to utf strings,
how foreach works, mixins, arrays, etc. But it isn't intended to be loaded
with novel ideas, it's a refactoring and refinement of existing and proven
ideas. D is an engineering job, not an academic research project.


Mixins are just like C-Macros with nicer synthax and less abilities. The way
arrays are done isn't realy a "significant novel idea", is it?

Anyway I didn't say anithing negative about D. I just said, that there anren't
any revolutionary ideas or anything like that.
Sep 07 2004
next sibling parent reply I.H.S <I.H.S_member pathlink.com> writes:
In article <chjude$2ab3$1 digitaldaemon.com>, Matthias Becker says...

D does have some significant novel ideas, like its approach to utf strings,
how foreach works, mixins, arrays, etc. But it isn't intended to be loaded
with novel ideas, it's a refactoring and refinement of existing and proven
ideas. D is an engineering job, not an academic research project.


Mixins are just like C-Macros with nicer synthax and less abilities. The way
arrays are done isn't realy a "significant novel idea", is it?

Anyway I didn't say anithing negative about D. I just said, that there anren't
any revolutionary ideas or anything like that.


Mr.Matthias!

'Revolutonizing C/C++ through a true and modern successor' which, infact, is a
cunning and tempting idea to achieve dominance of the modern computer
programming world.
D , on the other hand, is the true and pure Evolution of C/C++ , having the
objective of serving the programmer world and not enslaving it :D !
My Salute to Mr.Walter Bright.
Irfan Hussain Sheikh,
Pakistan.
Sep 07 2004
parent Matthias Becker <Matthias_member pathlink.com> writes:
Mr.Matthias!

'Revolutonizing C/C++ through a true and modern successor' which, infact, is a
cunning and tempting idea to achieve dominance of the modern computer
programming world.
D , on the other hand, is the true and pure Evolution of C/C++ , having the
objective of serving the programmer world and not enslaving it :D !
My Salute to Mr.Walter Bright.
Irfan Hussain Sheikh,
Pakistan.


IMHO the true and pure evolution of C/c++ is C++/CLI
Sep 07 2004
prev sibling next sibling parent "Walter" <newshound digitalmars.com> writes:
"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:chjude$2ab3$1 digitaldaemon.com...

D does have some significant novel ideas, like its approach to utf




strings,

how foreach works, mixins, arrays, etc. But it isn't intended to be




loaded

with novel ideas, it's a refactoring and refinement of existing and




proven

ideas. D is an engineering job, not an academic research project.


 Mixins are just like C-Macros with nicer synthax and less abilities.


From some perspectives, all templates are are glorified macros <g>.


 The way arrays are done isn't realy a "significant novel idea", is it?


One would think so, but looking at how arrays are so badly done in other
languages (look at VLA's in C), perhaps it is novel. Sometimes good ideas
are obvious only in hindsight.


 Anyway I didn't say anithing negative about D. I just said, that there


anren't

 any revolutionary ideas or anything like that.


I'm agreeing with you! I was just trying to point out the reasons why for
those that may think of it as a negative.
Sep 07 2004
prev sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Matthias Becker wrote:


 Mixins are just like C-Macros with nicer synthax and less abilities.


Then you haven't understood mixins. Using them like C-Macros is just one of
several applications. A number of novel ideas to use them have already
appeared on this list. Many more will probably be found in the future.

It is true that there are things that C-macros can do which cannot be done
in D. Anyhow: most of these deal with changing the syntax of the language,
and I seriously doubt that it is necessary to have that capability in the
language.

One of the greatest dangers of D is that it looks so similar to C/C++, that
you want to stick with the old way of thinking. Instinctively, you try to
use the same kind of crutches that you got used to use in C/C++ instead of
just starting to walk freely...
Sep 10 2004
parent "Walter" <newshound digitalmars.com> writes:
"Norbert Nemec" <Norbert Nemec-online.de> wrote in message
news:chrjic$14kl$1 digitaldaemon.com...

 One of the greatest dangers of D is that it looks so similar to C/C++,


that

 you want to stick with the old way of thinking. Instinctively, you try to
 use the same kind of crutches that you got used to use in C/C++ instead of
 just starting to walk freely...


My first large C program looked just like FORTRAN <g>. (guess I'm showing my
age)
Sep 10 2004
prev sibling parent "Lynn Allan" <l.allan att.net> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:chjccc$21j0$1 digitaldaemon.com...

 D does have some significant novel ideas, like its approach to utf


strings,

 how foreach works, mixins, arrays, etc. But it isn't intended to be loaded
 with novel ideas, it's a refactoring and refinement of existing and proven
 ideas. D is an engineering job, not an academic research project.


<alert comment="newbie">

Something that was mentioned earlier in a similar post:

Perhaps a great deal of thought should be given to features that could and
should be removed. (I suppose The WB and others have already gone through
this mental exercise at least several times.)

One of the better programmers that I worked with used to say: "One way to
tell if software is nearing completion is if there is nothing left to take
out."

Pre ver 1.0 is pretty much the last opportunity to remove rarely used and
problematic features. For each capability, does it pass the test of being
rock solid and essential?  For the remaining bug-list, would it make sense
to simply take out the associated feature altogether, for eventual
implementation post 1.0?

This approach might also have the advantage of getting ver 1.0 released
sooner. If remaining problems with obscure capability XYZ are holding up
release 1.0, then defer XYZ.

Speaking only for myself, I am not particularly concerned about when ver 1.0
becomes available. As of now, it more than meets my limited needs. I suppose
if my freeware project depended on the availability of obscure capability
XYZ, and it turned out that it wasn't available in ver 1.0, I'd be upset.

</alert>
Sep 07 2004
prev sibling next sibling parent Andy Friesen <andy ikagames.com> writes:
Helmut Leitner wrote:

 As so many have written about 1.0 I feel the urgent need to add my $0.02
 
 First of all I do not care about when D 1.0 will be released. This is
 totally unimportant to me (within a plausible time range of 3-12 months
 from now, of course). The only really important thing is:
 
   * post-1.00-changes to the compiler must NOT break 1.00 code
 
 I just revived some 0.79 test code and I had to insert a lot of casts
 and change all op-overloading methods. Also function parameter type 
 matching seems to have changed, for float expressions won't match with
 a long parameter function signature anymore (more casts!). 
 
 While these changes may make sense it was frustrating work for nothing. 
 It is acceptable to me in 0.xxx but would not be going from 1.00 to 1.01
 
 I know at least 3 contributors who struggled through the undig project to
 bring it up to date with dmd 0.1xx. After removing formal errors some
 examples still won't work (as they did some time ago; problems in 
 Windows API interfacing?). 
 
 The bottom line is: whatever you wish for 1.00 it will be of no significance 
 if the code written for dmd 1.00 will not compile and execute flawlessly in
the 
 dmd 3.27 of 2010. So its not so much about what features to include now,
 but about when to restrict the headroom for fundamental changes.
 
 BTW my best guess is that 0.127 will be 1.00
 I'm thinking about a website where you can place your bets!  :-)


I think it's really important that this /not/ strictly be the case. 
Time is a heck of a good teacher, and D needs to be able to take 
advantage of the lessons it offers.

What would be quite possible is to define a standard pragma to declare 
the version of D a module was written for.  Compiler implementations are 
then free to either error out elegantly, spew out a warning, or even 
shift gears and compile the older version of the spec.  A good compiler 
implementation, then, would be able to handle ten year old code without 
any issues, and all without forcing D into the same downward spiral that 
doomed C. :)

Incompatible changes are still a big deal, of course, but if, for 
example, the D group were to decide that a boolean type is in fact 
necessary, they should be allowed to break existing code and add a 
'boolean' keyword instead of being forced to use something like 
'__Boolean' and define all sorts of implicit conversions just to 
preserve the behaviour of existing code.

Of course, incompatible changes within a major version (1.1, 1.2, etc) 
should be forbidden: breaking existing code is pretty major. :)

  -- andy
Sep 06 2004
prev sibling parent Martin <Martin_member pathlink.com> writes:
I agree that we must create a good standard now that needs not much changing
later. And I think it is very important to make a collection of RESERVED WORDS.
To think carefully, what things might be in future dmd releases and to reserve
words for them.

I would suggest that we reserve everything beginning with d_ (d_in, d_with,
d_style, d_whatever ...)
Then we can take kewords whenever we want to without breaking any existing code.


And I think we should have a public discussion about what words should be
reserved.


In article <413C702D.9F2A116 hls.via.at>, Helmut Leitner says...

As so many have written about 1.0 I feel the urgent need to add my $0.02

First of all I do not care about when D 1.0 will be released. This is
totally unimportant to me (within a plausible time range of 3-12 months
from now, of course). The only really important thing is:

  * post-1.00-changes to the compiler must NOT break 1.00 code

I just revived some 0.79 test code and I had to insert a lot of casts
and change all op-overloading methods. Also function parameter type 
matching seems to have changed, for float expressions won't match with
a long parameter function signature anymore (more casts!). 

While these changes may make sense it was frustrating work for nothing. 
It is acceptable to me in 0.xxx but would not be going from 1.00 to 1.01

I know at least 3 contributors who struggled through the undig project to
bring it up to date with dmd 0.1xx. After removing formal errors some
examples still won't work (as they did some time ago; problems in 
Windows API interfacing?). 

The bottom line is: whatever you wish for 1.00 it will be of no significance 
if the code written for dmd 1.00 will not compile and execute flawlessly in the 
dmd 3.27 of 2010. So its not so much about what features to include now,
but about when to restrict the headroom for fundamental changes.

BTW my best guess is that 0.127 will be 1.00
I'm thinking about a website where you can place your bets!  :-)

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Sep 06 2004