Conversation
|
Thanks for your pull request and interest in making D better, @Bolpat! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please see CONTRIBUTING.md for more information. If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment. Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. |
|
The specification should be exact. If there are valid |
Agreed.
Trying to be absolutely technically correct with grammar here would be madness. The reason is that there are simply too many syntactic ways to express the
My best take: MainFunction:
StorageClasses? MainReturnType main MainParameters? FunctionAttributes? MainFunctionBody
StorageClasses main MainParameters? FunctionAttributes? MainFunctionBody
MainReturnType:
MainReturnBasicType
TypeCtor ( TypeCtors? MainReturnBasicType )
MainReturnBasicType:
void
int
Identifier
MainParameters:
( MainParameter )
( MainParameter , )
MainParameter:
MainParameterDeclaration
MainParameterDeclaration = AssignExpression
MainParameterDeclaration:
ParameterAttributes? MainParameterBasicType MainParameterTypeSuffixes? Identifier?
MainParameterBasicType:
char
TypeCtor ( TypeCtors? MainParameterBasicType MainParameterTypeSuffixes? )
Identifier
MainParameterTypeSuffixes:
[ ]
[ ] [ ]
MainFunctionBody:
SpecifiedFunctionBody
ShortenedFunctionBody
(Essentially, I ended up repeating the The In For some reason, the parameter of The fact that the parameter type can both be Doing the above again for the CMainFunction:
StorageClasses? extern ( C ) StorageClasses? MainReturnType main CMainParameters? FunctionAttributes? MainFunctionBody
CMainParameters:
CMainParameterList
CMainParameterList ,
CMainParameterList:
CMainFirstParameter , CMainNextParameter
CMainFirstParameter , CMainNextParameter , CMainNextParameter
CMainFirstParameter:
CMainFirstParameterDeclaration
CMainFirstParameterDeclaration = AssignExpression
CMainNextParameter:
CMainNextParameterDeclaration
CMainNextParameterDeclaration = AssignExpression
CMainFirstParameterDeclaration:
ParameterAttributes? CMainFirstParameterBasicType Identifier?
CMainFirstParameterBasicType:
int
TypeCtor ( TypeCtors? CMainFirstParameterBasicType )
Identifier
CMainNextParameterDeclaration:
ParameterAttributes? CMainNextParameterBasicType CMainParameterTypeSuffixes? Identifier?
CMainNextParameterBasicType:
char
TypeCtor ( TypeCtors? MainParameterBasicType CMainParameterTypeSuffixes? )
Identifier
CMainParameterTypeSuffixes:
*
* *
I’ll translate that into the DDoc syntax if you think that’s valuable. Otherwise I’d rather remove the grammar part and just explain the declaration with prose. |
|
Nice comprehensive analysis! I wouldn't make the grammar more complex but I wouldn't completely remove it either, the current grammar strikes a nice balance. The variations can be explained in prose like this: "Other formulations that result in a I think that covers all variations, barring the type
I think those are both the case, so the spec could mention it's a char[][] that's considered unique so it may convert to string[]. |
daceda3 to
04998f9
Compare
|
@ntrel, this should be good to go. Please have a look and if it’s good, merge. |
|
I prefer Dennis's suggestion, I think that's clearer. (I don't have merge rights). |
|
The current formulation:
What exactly do you want to replace by “Other formulations that result in a |
|
I think that sentences can be appended without replacing existing sentences in that paragraph. |
In particular, replace “must be declared” by “is typically declared,” as many variants are possible.