www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - improving the D spec

reply Christian Kamm <kamm-incasoftware removethis.de> writes:
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.

Here is the list:

major missing documentation
 + 3007 stringof
 * IFTI

grammar & mangles
 * 1466 maximal munch can't lex 1..3 correctly
 * 2734 float literal tokenization
 * 1351 multiple variable declarations with auto
 * 2392 parsing ambiguity: function pointer declaration / function call
 * 1351, 2406
 + 3029 ambiguous array value mangling for template alias args
 + 3043 more ambiguous template mangles

ABI
 * 690 data layout for various interface inheritance
 * 2385 structs are returned in registers on linux
 * 2648 function return ABI exceptions for Windows
 
parameter storage classes
 * 955 parameter storage classes underdocumented
 * 1411 storage classes applied to tuples
 * 1424 manipulating storage classes in tuples
 * 1818 storage classes in tuples discarded for function declarations

property syntax
 + 678 for a function f returning an array, f.ptr sometimes fails
 + 1600 can't call foo(T[]) as array.foo;
 + 2152 opIndex and opIndexAssign on the returned value
 + 2774 can't get mangleof of function

protection
 * 1920 protection and default protection for classes underdocumented
 * 2417 calling protected class member functions
 + 2529 package protection
 + 1441, 2830 protection for type declarations

template ordering
 * 918 alias parameters
 * 2025 variadic templates
 * 1650 spec references 'C++ rules'

no bugzilla:
 * a.foo(...) -> foo(a, ...) transform for a array not documented
 * 'mangleof' can't be member of a struct not documented (other properties?)
 * what operations call the gc?

other
 * 52 auto fp = &overloaded_foo
 * 603 scopes in switch statements
 * 632 typedef/enum promotions
 * 869 precedence for is, !is
 * 996 error in example, ptr = array
 * 1351 non-terminals should be links
 * 2179 imports in class scopes
 * 1418 tupleof on nested classes
 * 1521 documentation on scope classes ambiguous
 * 1528 cannot overload functions and template functions
 * 1563 cast(C)v for class C only performs a dynamic cast for certain
        types of v
 * 1626 what exactly does if(v) do for various types of v?
 * 2017 explain common use of literal[] to get a dynamic array
 * 2201 end of line in string literals
 * 2351 empty enums
 * 2382 what can be a global/static initializer?
 * 2387 definition of 'static array'
 * 2395 struct forward declarations
 * 2497 deleting null
 * 2522 result type of binary operators
 * 2554 pragma(lib,...) must be declaration
 * 2616 part-explicit IFTI
 * 3093 Object.factory
 * 1142 stringof performs semantic analysis
 * 2482 magic struct operator overloads
 * 2028 module and package lookup
 * 2093 arrays and slices and lengths
 * 2106 export and classes
 * 2486 taking address of slice rvalues is valid
 + 302 contract inheritance
 + 502 reimplement interface functions with aliases
 + 671 overloading class opAssign allows initialization with it but
       generates useless code
 + 1429 associative array ==, !=
 + 2358 offsetof property usage inconsistent between structs and classes
 + 2477 trailing commas in array literals
 + 2524 final override + interface
 + 2543 foreach index refness
 + 2632 operations on invalid arrays
 + 2701 opAssign for struct initialization
 + 2716 'auto' still has meaning of 'scope' sometimes
 + 2733 semantics of template value parameters
 + 2894 abstract functions
 + 3005 for statement allows more than declarations in first arg
 + 3066 array operations as initializers
 + 3085 cannot index tuple in declaration

as intended?
 * 1715 convertibility vs. equality in template specializations
 * 1012 cannot instantiate template with no parameters or default parameters
        without !()
Jun 29 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Jun 29, 2009 at 4:20 PM, Christian
Kamm<kamm-incasoftware removethis.de> wrote:

 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 :)
Jun 29 2009
next sibling parent reply Christian Kamm <kamm-incasoftware removethis.de> writes:
Jarrett Billingsley wrote:

 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.
Jun 29 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jun 30, 2009 at 2:06 AM, Christian
Kamm<kamm-incasoftware removethis.de> wrote:

 Jarrett Billingsley wrote:

 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).
Jun 30 2009
prev sibling parent Tim Matthews <tim.matthews7 gmail.com> writes:
Jarrett Billingsley wrote:


 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
Jul 06 2009
prev sibling next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
Christian Kamm wrote:

 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 !()


This is a huge list, congrats on compiling it!
Jun 29 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Christian Kamm, el 29 de junio a las 22:20 me escribiste:

 
 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:


 major missing documentation
  + 3007 stringof
  * IFTI


No meta-bug, it's just one bug...


 grammar & mangles
  * 1466 maximal munch can't lex 1..3 correctly
  * 2734 float literal tokenization
  * 1351 multiple variable declarations with auto
  * 2392 parsing ambiguity: function pointer declaration / function call
  * 1351, 2406
  + 3029 ambiguous array value mangling for template alias args
  + 3043 more ambiguous template mangles


Any distinction between '*' and '+'? 1351 is duplicated, did you mean
other bug?

Here is the meta-bug:
http://d.puremagic.com/issues/show_bug.cgi?id=3104


 ABI
  * 690 data layout for various interface inheritance
  * 2385 structs are returned in registers on linux
  * 2648 function return ABI exceptions for Windows


http://d.puremagic.com/issues/show_bug.cgi?id=3105


 parameter storage classes
  * 955 parameter storage classes underdocumented
  * 1411 storage classes applied to tuples
  * 1424 manipulating storage classes in tuples
  * 1818 storage classes in tuples discarded for function declarations


http://d.puremagic.com/issues/show_bug.cgi?id=3106


 property syntax
  + 678 for a function f returning an array, f.ptr sometimes fails
  + 1600 can't call foo(T[]) as array.foo;
  + 2152 opIndex and opIndexAssign on the returned value
  + 2774 can't get mangleof of function


http://d.puremagic.com/issues/show_bug.cgi?id=3107


 protection
  * 1920 protection and default protection for classes underdocumented
  * 2417 calling protected class member functions
  + 2529 package protection
  + 1441, 2830 protection for type declarations


http://d.puremagic.com/issues/show_bug.cgi?id=3108


 template ordering
  * 918 alias parameters
  * 2025 variadic templates
  * 1650 spec references 'C++ rules'


http://d.puremagic.com/issues/show_bug.cgi?id=3109


 no bugzilla:


I've opened new bugs for these:


  * a.foo(...) -> foo(a, ...) transform for a array not documented


http://d.puremagic.com/issues/show_bug.cgi?id=3110


  * 'mangleof' can't be member of a struct not documented (other properties?)


http://d.puremagic.com/issues/show_bug.cgi?id=3111


  * what operations call the gc?


http://d.puremagic.com/issues/show_bug.cgi?id=3112


 other
  * 52 auto fp = &overloaded_foo
  * 603 scopes in switch statements
  * 632 typedef/enum promotions
  * 869 precedence for is, !is
  * 996 error in example, ptr = array
  * 1351 non-terminals should be links
  * 2179 imports in class scopes
  * 1418 tupleof on nested classes
  * 1521 documentation on scope classes ambiguous
  * 1528 cannot overload functions and template functions
  * 1563 cast(C)v for class C only performs a dynamic cast for certain
         types of v
  * 1626 what exactly does if(v) do for various types of v?
  * 2017 explain common use of literal[] to get a dynamic array
  * 2201 end of line in string literals
  * 2351 empty enums
  * 2382 what can be a global/static initializer?
  * 2387 definition of 'static array'
  * 2395 struct forward declarations
  * 2497 deleting null
  * 2522 result type of binary operators
  * 2554 pragma(lib,...) must be declaration
  * 2616 part-explicit IFTI
  * 3093 Object.factory
  * 1142 stringof performs semantic analysis
  * 2482 magic struct operator overloads
  * 2028 module and package lookup
  * 2093 arrays and slices and lengths
  * 2106 export and classes
  * 2486 taking address of slice rvalues is valid
  + 302 contract inheritance
  + 502 reimplement interface functions with aliases
  + 671 overloading class opAssign allows initialization with it but
        generates useless code
  + 1429 associative array ==, !=
  + 2358 offsetof property usage inconsistent between structs and classes
  + 2477 trailing commas in array literals
  + 2524 final override + interface
  + 2543 foreach index refness
  + 2632 operations on invalid arrays
  + 2701 opAssign for struct initialization
  + 2716 'auto' still has meaning of 'scope' sometimes
  + 2733 semantics of template value parameters
  + 2894 abstract functions
  + 3005 for statement allows more than declarations in first arg
  + 3066 array operations as initializers
  + 3085 cannot index tuple in declaration
 
 as intended?
  * 1715 convertibility vs. equality in template specializations
  * 1012 cannot instantiate template with no parameters or default parameters
         without !()


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?
Jun 29 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Leandro Lucarella, el 29 de junio a las 22:46 me escribiste:

 Christian Kamm, el 29 de junio a las 22:20 me escribiste:

 
 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:
 

 major missing documentation
  + 3007 stringof
  * IFTI


 
 No meta-bug, it's just one bug...


I'm sorry, there are 2, but "IFTI" is not reported yet. I would report it
myself but I don't know exactly what is about =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Jun 29 2009
prev sibling parent Christian Kamm <kamm-incasoftware removethis.de> writes:
Leandro Lucarella wrote:

 Thank you for the great job. Following your example, I created a meta-bug
 for each category to easily keep track of them =)


Thanks! I was not sure how to make the groupings permanent - and putting it 
directly into bugzilla is a good idea! 


 Any distinction between '*' and '+'? 1351 is duplicated, did you mean
 other bug?


I think bugs with a * might be fixable without touching the compiler, while 
+ bugs probably aren't. I think 1351 was in there twice for a reason, it 
contains more than one issue.
Jun 29 2009