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.

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).

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).

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). 
> 
> 
> 

>
> 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.

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

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.

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.

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

#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

> 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.