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

http://www.wikiservice.at/wiki4d/wiki.cgi?PendingPeeves


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.

digitalmars.D.bugs/2643
digitalmars.D.bugs/4556
digitalmars.D/27376

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

digitalmars.D.bugs/2642

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

D/27548

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.

digitalmars.D.bugs/3669
digitalmars.D.bugs/4124

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.

http://www.digitalmars.com/d/statement.html#return

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

digitalmars.D.bugs/4828
digitalmars.D.bugs/4829


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

digitalmars.D.bugs/2001
digitalmars.D.bugs/3170
digitalmars.D.announce/962

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

http://www.digitalmars.com/d/errors.html

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

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

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?

digitalmars.D.bugs/3843


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

D/27490

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?

digitalmars.D.bugs/2365

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.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
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
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.
Sep 08 2005