www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Mustfixes before v.1.0

reply "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. 
May 03 2005
parent reply "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).

May 03 2005
parent reply "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). 


May 03 2005
parent reply 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). 



May 03 2005
parent reply "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.
May 03 2005
parent reply 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.

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
May 03 2005
parent reply 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.
May 03 2005
parent reply 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 as with the "#" prefix in CPP. I am convinced this is the correct way. 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.
May 03 2005
next sibling parent 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.

1) Changes in the language semantics prevent old code from compiling 2) Changes in the ABI stop objects from linking #1 can be fixed up in a couple of ways 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 #2) is again not too hard to fix I think 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
May 04 2005
prev sibling parent "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 
 as with the "#" prefix in CPP.  I am convinced this is the correct way.

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.
May 04 2005