www.digitalmars.com         C & C++   DMDScript  

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

The Pending Peeves page seems to have gone rather quiet lately.  Rest 
assured it's still being maintained, and has indeed been updated a bit 
over the last few weeks.  And admittedly, waiting for them to be dealt 
with is getting tiring again....


The bugs, documentation holes, debates, whatever of AAs and Object.opCmp 
seem to be here to stay.  There has also been talk of another AA issue: 
the false matches that occur if equivalence by opCmp isn't the same as 
equality by opEquals.  At first it seemed to be happening only with 
struct keytypes, but now I've found that it's happening with class 
keytypes as well.


However, one good thing seems to have happened: since this issue


was raised, it seems to have changed so that a struct keytype can have 
opCmp defined to take either a value or a pointer.  However, if it's 
defined with an inout parameter, it screws up (need to experiment with 
this a bit more).  Next question: ought == != < <= > >= (and indeed 
other operators) to work with either value or pointer to match?

Bit arrays now concatenate properly for a change.  Bit array slicing has 
been working for a while, but only if the slice begins on a byte 
boundary.  Is this the way it's going to stay?  If this is confirmed, 
then we can call this issue done.

Speaking of things marked "done?" on here, is Kris still here?  Could 
you please confirm if this


is working properly now?

But other old bugs (and even one or two not-so-old bugs) die hard.

A regression that happened in 0.116 or thereabouts is still waiting to 
be fixed: functions with a non-void return type but no return statements 
slip through the compiler.


Although there's been a case or two for allowing not all paths through a 
function to return something, there is still no reason to light for such 
a function to have no return statements at all, especially if it has no 
throw statements or literal assert(false) either.  And although Walter 
has been pretending otherwise, this is indeed a bug.


"At least one return statement is required if the function specifies a 
return type that is not void."

And since this bug has bitten many, who have had to post here to ask 
what's wrong, it's about time this was fixed.

And here are two bugs that seem to have hidden their faces for ages, 
both of which seem to be bits of DMD confusing D with C.  The first is 
that the compiler accepts ';' by itself as a statement that does nothing 
- nothing in the spec allows this, and it seems to have no use 
whatsoever.  The bug has even cropped up in contexts where the very 
design of D is to disallow it.  The second is that expression statements 
that do nothing, which are illegal, are not caught by the compiler at all.


The issue of where uncaught errors are output has cropped up again.


Maybe I should do a little round-up of the issue here.


"If no catch handlers are there for the errors, then the program 
gracefully exits through the default error handler with an appropriate 

If an error message is redirected when the user didn't ask for it, 
possibly even piped to another program or called by Doxygen to process 
the output, then this isn't gracefully exiting.  stderr exists for one 
reason: to enable the user of a program to see errors immediately, and 
not be misled that the program has done its job, if output has been 

Walter once claimed that he doesn't really like stderr as certain 
platforms don't provide a means of redirecting it.  But this should be 
up to the user, not the programmer, and certainly not up to the creator 
of the language that the program was written in (unless it's an esolang 
with this inherent limitation, which D isn't).  The user has the choice 
of using a third-party tool to redirect stderr as well, or of not using 
one and having errors output to the console.  We shouldn't be taking 
this choice away.

There isn't much new stuff that can be said of the things that still 
need to be clarified in the spec.  Besides: why is there not a single 
"DONE" in the second category of peeves?  Oops ... I almost forgot about 
the typedef arithmetic problem.  Was it as recent as 0.121 that this 
cropped up?  Or should I say: Was it that long ago that 0.121 was around?


std.date is still on the woefully deficient side, albeit with certain 
fundamental functions now merely undocumented rather than missing.


Though some of them do still misuse the d_time type.  This would be a 
trivial fix.  Shall we fix them to adhere to one or two naming 
conventions while we're at it?


At least I did get round to releasing a utility library containing 
better date/time stuff.  But still, that doesn't alter the fact that 
Phobos should be cleaned up....

And array operations are *still* a feature that's in the language but 
not in the compiler.


Version: 3.1
GCS/M d- s:- 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.
Sep 08 2005