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.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2643
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4556
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/27376

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

http://www.digitalmars.com/drn-bin/wwwnews?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

http://www.digitalmars.com/drn-bin/wwwnews?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.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3669
http://www.digitalmars.com/drn-bin/wwwnews?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.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4828
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4829


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

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2001
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3170
http://www.digitalmars.com/drn-bin/wwwnews?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?

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3843


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

http://www.digitalmars.com/drn-bin/wwwnews?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?

http://www.digitalmars.com/drn-bin/wwwnews?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.