In the wake of the recent 'state of D' articles, I've looked at the D1 spec
bugs on bugzilla and grouped them by topic. I've also separated them into
issues that probably need compiler changes (+) and bugs that might be
resolved by a spec change (*).
My plan is to go through the issues and to write up spec patches where the
resolution is clear. This should cover a fair number of bugs, in particular
those of the 'missing documentation' kind. If there's doubt as to what
should be done, I'll assign to Walter and might bring the discussion to the
newsgroup.
To show that this - apart from being useful for compiler developers and
users alike - is far from boring, I'll present some facts I learned while
experimenting with template ordering and IFTI in a separate post.
Unfortunately, the list is very long and thus I hope that more people will
contribute patches. Sure, fixing bugs in the spec doesn't change the
compiler or add a cool new feature, but I sincerely hope that it will make D
more mature and simpler to implement.

Wow, you're awesome. Seriously.
This is quite a coincidence. Just yesterday, I created a Trac
environment on my website to, uh, well, respecify D.
http://www.jfbillingsley.com/dspec/
Nothing terribly pretty yet, and there's really only the Lexical
section done, but if you'd like, I can get you write access to it. As
well as anyone else who's interested. I plan on having are
'rationale' sections to explain why features are chosen, and
'questions' sections for clarifying points in a Q&A format. And of
course, being a Wiki, it should be much easier to modify.
Input from an implementer of a D compiler would be greatly welcomed :)

Nothing terribly pretty yet, and there's really only the Lexical
section done, but if you'd like, I can get you write access to it. As
well as anyone else who's interested. I plan on having are
'rationale' sections to explain why features are chosen, and
'questions' sections for clarifying points in a Q&A format. And of
course, being a Wiki, it should be much easier to modify.

Yes! That'd be excellent to have. Would you mind if I used it as a
scratchpad for possible spec texts? Editing them collaboratively will be
much easier in a wiki.

http://www.jfbillingsley.com/dspec/
Nothing terribly pretty yet, and there's really only the Lexical
section done, but if you'd like, I can get you write access to it. As
well as anyone else who's interested. I plan on having are
'rationale' sections to explain why features are chosen, and
'questions' sections for clarifying points in a Q&A format. And of
course, being a Wiki, it should be much easier to modify.

This is a great start. I greatly appreciate all efforts by anyone to
improve the D spec. Thanks

In the wake of the recent 'state of D' articles, I've looked at the D1 spec
bugs on bugzilla and grouped them by topic. I've also separated them into
issues that probably need compiler changes (+) and bugs that might be
resolved by a spec change (*).
My plan is to go through the issues and to write up spec patches where the
resolution is clear. This should cover a fair number of bugs, in particular
those of the 'missing documentation' kind. If there's doubt as to what
should be done, I'll assign to Walter and might bring the discussion to the
newsgroup.

Thank you, thank you, thank you! *This* is exactly what is needed for D
to get somewhere in my opinion. I'm so glad you've volunteered for this!
Once D has a decent working spec D1 will finally be truely 'stable' :D

To show that this - apart from being useful for compiler developers and
users alike - is far from boring, I'll present some facts I learned while
experimenting with template ordering and IFTI in a separate post.
Unfortunately, the list is very long and thus I hope that more people will
contribute patches. Sure, fixing bugs in the spec doesn't change the
compiler or add a cool new feature, but I sincerely hope that it will make D
more mature and simpler to implement.
Here is the list:
major missing documentation
+ 3007 stringof

-- Snip --

* 1012 cannot instantiate template with no parameters or default parameters
without !()

In the wake of the recent 'state of D' articles, I've looked at the D1 spec
bugs on bugzilla and grouped them by topic. I've also separated them into
issues that probably need compiler changes (+) and bugs that might be
resolved by a spec change (*).
My plan is to go through the issues and to write up spec patches where the
resolution is clear. This should cover a fair number of bugs, in particular
those of the 'missing documentation' kind. If there's doubt as to what
should be done, I'll assign to Walter and might bring the discussion to the
newsgroup.
To show that this - apart from being useful for compiler developers and
users alike - is far from boring, I'll present some facts I learned while
experimenting with template ordering and IFTI in a separate post.
Unfortunately, the list is very long and thus I hope that more people will
contribute patches. Sure, fixing bugs in the spec doesn't change the
compiler or add a cool new feature, but I sincerely hope that it will make D
more mature and simpler to implement.

Thank you for the great job. Following your example, I created a meta-bug
for each category to easily keep track of them =)
This is the extended list with the meta-bugs:

All these (and the new bugs) should be categorized. Unfortunatelly I don't
have time to do it myself right now, but anyone else with a couple of
minutes can take it from here =)
I've added the new bugs as blockers for 677 which already group all
spec-related issues:
http://d.puremagic.com/issues/show_bug.cgi?id=677
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Hey you, out there in the cold
Getting lonely, getting old
Can you feel me?

In the wake of the recent 'state of D' articles, I've looked at the D1 spec
bugs on bugzilla and grouped them by topic. I've also separated them into
issues that probably need compiler changes (+) and bugs that might be
resolved by a spec change (*).
My plan is to go through the issues and to write up spec patches where the
resolution is clear. This should cover a fair number of bugs, in particular
those of the 'missing documentation' kind. If there's doubt as to what
should be done, I'll assign to Walter and might bring the discussion to the
newsgroup.
To show that this - apart from being useful for compiler developers and
users alike - is far from boring, I'll present some facts I learned while
experimenting with template ordering and IFTI in a separate post.
Unfortunately, the list is very long and thus I hope that more people will
contribute patches. Sure, fixing bugs in the spec doesn't change the
compiler or add a cool new feature, but I sincerely hope that it will make D
more mature and simpler to implement.

Thank you for the great job. Following your example, I created a meta-bug
for each category to easily keep track of them =)
This is the extended list with the meta-bugs:

Nothing terribly pretty yet, and there's really only the Lexical
section done, but if you'd like, I can get you write access to it. =A0As
well as anyone else who's interested. =A0I plan on having are
'rationale' sections to explain why features are chosen, and
'questions' sections for clarifying points in a Q&A format. =A0And of
course, being a Wiki, it should be much easier to modify.

Yes! That'd be excellent to have. Would you mind if I used it as a
scratchpad for possible spec texts? Editing them collaboratively will be
much easier in a wiki.

Sure! Just email me what username and password you'd like (you can
change the password after you log in, of course).