• Andrew Fedoniouk (24/24) May 03 2005 What they are?
• Unknown W. Brackets (15/23) May 03 2005 Personally, I read every one of the below, aside from 3 and I guess 4,
• Andrew Fedoniouk (8/33) May 03 2005 It is just not realistic to have the whole DStress done in foreseeable
• clayasaurus (2/52) May 03 2005
• Andrew Fedoniouk (7/8) May 03 2005 Ideally D should appear three/four months ago.
• Brad Beveridge (19/34) May 03 2005 For the small amount that it is worth, I agree that D should hit 1.0
• Mike Capp (11/16) May 03 2005 Depends what compatibility guarantees are going to be made, I think.
• Burton Radons (23/45) May 03 2005 Oblique observation: these faults are caused by languages not
• brad beveridge (17/21) May 04 2005 I agree, I don't see why a language can't grow. I see two issues
• Ben Hinkle (6/9) May 04 2005 Another way is before inroducing a new keyword you first have to "deprec...

"Andrew Fedoniouk" <news terrainformatica.com> writes:

What they are?

My candidate list:

1) Detection of function return values.
2) -w[arning] mode: fix of  "implicit conversion of expression (bool 
expression) of type int to bit can
cause loss of data"
3) 'package' access control attribute fix.
4) 'isnot' for the sake of completeness and for those guys who are not using
   "programming fonts" like Lucida Console (=== usability issue).
5) Eliminating runtime assertion in switch() without 'default'  (optional).

Having fixed this I would really consider DMD at version 1.0.
Any other items here?

Nice to have features:
1) "External methods". Canonization of current situation when
    foo(char[], int) can be invoked as "string".foo(1);
    To define this behavioir in doc and to allow such
    methods to be defined not only for arrays but for any
    POD type like:
       typedef uint Color;
       uint red(Color) {...}
       Color c;  uint r = c.red();  string s = c.toString();
   This is not only aesthetical requirement but nice to have feature
   for meta programming using templates.

Andrew. 

"Unknown W. Brackets" <unknown simplemachines.org> writes:

Personally, I read every one of the below, aside from 3 and I guess 4, 
as somewhat controversial.  It seems like Walter is very for them, and 
they have caused many arguments in the past.

Starting off with them is likely to get any posts in this thread totally 
ignored by Walter.

I'd really be most interested with having DStress run without flaw.  To 
me, those are things which are "mustfixes" - because strange or 
unexpected bugs and crashes would hurt this language a LOT MORE than an 
assert/HLT because of a missing return without warning.

As much as many may dislike these things (myself included, although I 
just don't see it as a reason to picket) they are at least *documented* 
and *expected* by those who bother to read about the language.  Bugs, on 
the other hand, are completely different.

Just my opinion.

-[Unknown]


 1) Detection of function return values.
 2) -w[arning] mode: fix of  "implicit conversion of expression (bool 
 expression) of type int to bit can
 cause loss of data"
 3) 'package' access control attribute fix.
 4) 'isnot' for the sake of completeness and for those guys who are not using
    "programming fonts" like Lucida Console (=== usability issue).
 5) Eliminating runtime assertion in switch() without 'default'  (optional).

"Andrew Fedoniouk" <news terrainformatica.com> writes:

It is just not realistic to have the whole DStress done in foreseeable
future.

Probably it is time now to revisit DStress bug clusters and classify them
on MF and FR (future release).

D time and opportunities is running out very quickly.

Andrew.


"Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
news:d58og9$724$1 digitaldaemon.com...
 Personally, I read every one of the below, aside from 3 and I guess 4, as 
 somewhat controversial.  It seems like Walter is very for them, and they 
 have caused many arguments in the past.

 Starting off with them is likely to get any posts in this thread totally 
 ignored by Walter.

 I'd really be most interested with having DStress run without flaw.  To 
 me, those are things which are "mustfixes" - because strange or unexpected 
 bugs and crashes would hurt this language a LOT MORE than an assert/HLT 
 because of a missing return without warning.

 As much as many may dislike these things (myself included, although I just 
 don't see it as a reason to picket) they are at least *documented* and 
 *expected* by those who bother to read about the language.  Bugs, on the 
 other hand, are completely different.

 Just my opinion.

 -[Unknown]


 1) Detection of function return values.
 2) -w[arning] mode: fix of  "implicit conversion of expression (bool 
 expression) of type int to bit can
 cause loss of data"
 3) 'package' access control attribute fix.
 4) 'isnot' for the sake of completeness and for those guys who are not 
 using
    "programming fonts" like Lucida Console (=== usability issue).
 5) Eliminating runtime assertion in switch() without 'default' 
 (optional). 

clayasaurus <clayasaurus gmail.com> writes:

Andrew Fedoniouk wrote:
 It is just not realistic to have the whole DStress done in foreseeable
 future.
 
 Probably it is time now to revisit DStress bug clusters and classify them
 on MF and FR (future release).
 
 D time and opportunities is running out very quickly.
 
 Andrew.
 

Why are D time and oppurtunities running out so quickly?


 
 "Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
 news:d58og9$724$1 digitaldaemon.com...
 
Personally, I read every one of the below, aside from 3 and I guess 4, as 
somewhat controversial.  It seems like Walter is very for them, and they 
have caused many arguments in the past.

Starting off with them is likely to get any posts in this thread totally 
ignored by Walter.

I'd really be most interested with having DStress run without flaw.  To 
me, those are things which are "mustfixes" - because strange or unexpected 
bugs and crashes would hurt this language a LOT MORE than an assert/HLT 
because of a missing return without warning.

As much as many may dislike these things (myself included, although I just 
don't see it as a reason to picket) they are at least *documented* and 
*expected* by those who bother to read about the language.  Bugs, on the 
other hand, are completely different.

Just my opinion.

-[Unknown]



1) Detection of function return values.
2) -w[arning] mode: fix of  "implicit conversion of expression (bool 
expression) of type int to bit can
cause loss of data"
3) 'package' access control attribute fix.
4) 'isnot' for the sake of completeness and for those guys who are not 
using
   "programming fonts" like Lucida Console (=== usability issue).
5) Eliminating runtime assertion in switch() without 'default' 
(optional). 


 
 
 

"Andrew Fedoniouk" <news terrainformatica.com> writes:

 Why are D time and oppurtunities running out so quickly?

Ideally D should appear three/four months ago.

Let's say that this is my personal feeling/analysis based on
increasing number of people/projects looking for solutions
out of "main stream"s. I am speaking about
UI design primarily as this is my main area of interests/
contacts.

Andrew. 

Brad Beveridge <brad somewhere.net> writes:

Andrew Fedoniouk wrote:
Why are D time and oppurtunities running out so quickly?

 
 
 Ideally D should appear three/four months ago.
 
 Let's say that this is my personal feeling/analysis based on
 increasing number of people/projects looking for solutions
 out of "main stream"s. I am speaking about
 UI design primarily as this is my main area of interests/
 contacts.
 
 Andrew. 
 
 

For the small amount that it is worth, I agree that D should hit 1.0 
soon.  It is very hard to take a language seriously when it is not 1.0. 
Now the reality is that all software has bugs and version number should 
be irrelevant, but until something hits 1.0 people just disregard it. 
IMHO, D is already much less buggy than a lot of mature software.
Is there any reason why Walter shouldn't
1) Freaze features as is
2) Fix the showstopper bugs
3) Release D 1.0
4) Continue work on an unstable D branch & only bugfix the original v1.0

Although D has some warts, it has to hit 1.0 at some time and you can't 
please all of the people all of the time.  At the moment I think that D 
pleases most of the people most of the time - and that should certainly 
be enough for 1.0

I don't know much about the warts that Phobos may have - but if the 
standard library is holding back v1.0, then maybe we (as a community) 
should put effort into getting Phobos up to scratch.

Brad

Mike Capp <mike.capp gmail.com> writes:

In article <d58tep$dcl$1 digitaldaemon.com>, Brad Beveridge says...

Is there any reason why Walter shouldn't
1) Freaze features as is
2) Fix the showstopper bugs
3) Release D 1.0
4) Continue work on an unstable D branch & only bugfix the original v1.0

Depends what compatibility guarantees are going to be made, I think.

A major release number often carries the implication that future releases will
be compatible with it. Helpful for inspiring confidence. Not so helpful if the
language is still trying to evolve.

C++ is lumbered with some real lemon features thanks to the need to maintain
source compatibility with pre-Standard ('this' being a pointer instead of a
reference) and Standard ('export', exception specifications) features. Java's
eventual implementation of generics was crippled by their unwillingness to break
binary compatibility. D doesn't (from my admittedly limited reading) strike me
as something ready to be set in stone.

Burton Radons <burton-radons smocky.com> writes:

Mike Capp wrote:
 In article <d58tep$dcl$1 digitaldaemon.com>, Brad Beveridge says...
 
 
Is there any reason why Walter shouldn't
1) Freaze features as is
2) Fix the showstopper bugs
3) Release D 1.0
4) Continue work on an unstable D branch & only bugfix the original v1.0

 
 
 Depends what compatibility guarantees are going to be made, I think.
 
 A major release number often carries the implication that future releases will
 be compatible with it. Helpful for inspiring confidence. Not so helpful if the
 language is still trying to evolve.
 
 C++ is lumbered with some real lemon features thanks to the need to maintain
 source compatibility with pre-Standard ('this' being a pointer instead of a
 reference) and Standard ('export', exception specifications) features. Java's
 eventual implementation of generics was crippled by their unwillingness to
break
 binary compatibility. D doesn't (from my admittedly limited reading) strike me
 as something ready to be set in stone.

Oblique observation: these faults are caused by languages not 
understanding that they are flawed and must change in the future.  A 
language should be designed to accept changes.  With a language such as 
D, there are three areas of concern:

1) Library changes.  This is handled by the "deprecated" keyword.  Not 
much more can be done by the language; maybe a DeprecatedException for 
when a library's acceptable input changes without changing the types.  I 
can picture an elaborate scheme to library versioning but it likely 
would be disused.

2) Semantic changes, such as if "this" were changed from a pointer in 
struct methods into an inout reference.  This requires either making the 
present codebase entirely bogus, not making a change which our more 
developed wisdom indicates is necessary and leaving it for the next 
language to revolt, or by indicating in the source what language version 
is provided.  I lean on the last.

3) Keyword changes, which is like 2 but has an additional solution: put 
keywords in a different namespace than identifiers by marking them, such 


Handling multiple language revisions is a burden on the compiler, but 
you know what?  That's okay.  It's when the language is contradictory or 
arbitrary that we start getting into problems.  If the compiler authors 
are given a list of changes with each revision they'll do fine.

brad beveridge <brad nowhere.com> writes:

Burton Radons wrote:
 Handling multiple language revisions is a burden on the compiler, but 
 you know what?  That's okay.  It's when the language is contradictory or 
 arbitrary that we start getting into problems.  If the compiler authors 
 are given a list of changes with each revision they'll do fine.

I agree, I don't see why a language can't grow.  I see two issues
1) Changes in the language semantics prevent old code from compiling
2) Changes in the ABI stop objects from linking


a) the compiler vendor can maintain multiple versions of the compiler, 
so just compiler your code with a legacy (but maintained) compiler.
b) fix your code so you can use the new features of the language - if 
compilers deprecate features gradually then this really shouldn't be too 
painful


a) for some ABI changes, the linker might need be able to fix linking & 
therefore you don't notice the ABI change at all
b) as long as the language can generate older versioned functions (much 
like D can export C functions) then you can create shims that do link to 
the older binaries.

Brad

"Ben Hinkle" <ben.hinkle gmail.com> writes:

 3) Keyword changes, which is like 2 but has an additional solution: put 
 keywords in a different namespace than identifiers by marking them, such 


Another way is before inroducing a new keyword you first have to "deprecate" 
the old identifier. That is, you warn for a few releases that a given 
identifier will soon become a keyword and then you switch the compiler to 
the keyword. The difference from library deprecation is that eventually the 
deprecated identifier will be removed whereas deprecated library feature 
might potientially stay forever if they don't get in the way.