www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The IX PPPR (Pending Peeves Progress Review)

I know, PPPRs normally come at the multiples of .10.  I intended to do 
one at 0.170, but new versions kept coming faster than I could keep up, 
and it kind of fell behind.



I've been working towards getting my personal bug list, including things 
that are in Pending Peeves, into Bugzilla.  Until recently, deprecation 
bugs were missing from Bugzilla.  Now the ones I've been found are reported.

and so on, up to

Next question: Are they going to be fixed soon?

The issues of the existence of Object.opCmp and the way AAs rely on it 
seem to have settled now.  The spec has been updated to reflect the 
current behaviour and, while some may still disagree with this strategy, 
at least it's better-defined.  However, we could still do with a decent 
explanation of why Object.opCmp exists, in the relevant part of 
operatoroverloading.html, for the many people who will continue to be 


Better-defined up to a point anyway - the fact that AAs ignore opEquals 
(contrary to the current spec) and just treat all objects for which 
opCmp returns 0 as equal is something that still needs to be done 
something about.


Controversy has struck again over the fact that the compiler accepts ';' 
as a statement.  I've always taken the view that it serves no purpose 
but to lead to mistakes.  Walter has since finally claimed something to 
the effect that it's useful to simplify the task of writing programs 
that generate D code, but I'm still not sure how.  And even if one does 
accept this, it should still not be allowed as the body of a control or 
conditional compilation statement.  The spec is currently in a mess here:


I'm not sure when it was that DMD was changed to allow an array to be 
concatenated with a single element.  However, this behaviour is, as far 
as I can tell, still undocumented.


At least we've now got a spec of how typedefs behave when arithmetically 
combined.  We've also had a handful of fixes for issues regarding return 
covariance involving interfaces.  I think this issue is all fixed now, 
but I'm not entirely sure.

I've just noticed that some improvements have been made to std.file.  A 
new Unix version of copy has been written, which now preserves 
timestamps and works on large files.  (At least I assume it works - I 
haven't had the chance to test it.)  But it's rather long-winded.  I 
guess we can call this done now.  I don't know _when_ it was done - the 
changelog appears not to list it.

Good to see that we now have a function to get file timestamps in std.file.

The effort to translate the Windows API headers has gone quiet again. 
If we're going to have a translation ready for 1.0, we'd better get back 
into it!


Speaking of 1.0, Walter has now announced a date on which he hopes to 
release it.  However, the date seems rather too close for D's own good. 
  At the moment, we're still waiting for, among other things:
- an answer to even one d1.0blocker nomination, let alone the lot
- a sure sign of a 1.0 feature freeze


I'll finish off with two things that are being left far too late:

- Folding in the fix to make unhandled errors output to stderr, where 
they belong, instead of stdout.  What's taking so long about such a 
trivial operation that's had all excuses against it debunked?


- Implementing inheritance of in/out contracts.  A suitable strategy has 
been given - how about getting on with actually doing it?


Until next time....


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

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Nov 27 2006