dotnet
Unify `array_type` and `array type` usage in the specification
There are a number of places in the spec that talk about arrays and their types, but they do not use a consistent phrase; instead, some use array_type, and some use array type. As an example, type inference uses array type, while conversions use array_type. This makes it difficult to track down all the behavior associated with array types in the specification. It seems like the spec should unify on array_type, rather than array type, but I don't have a real opinion other than it shouldn't use both.
@333fred, @jskeet, @BillWagner In principle, I agree; however, this is just one instance of a much larger situation.
We often define a grammar rule name of the form xxx_yyy, but thereafter refer to it in narrative simply as "xxx yyy" and sometimes using the italicized rule name. (See type_declaration vs. "type declaration," class_declaration vs. "class declaration," struct_declaration vs. "struct declaration," interface_declaration vs. "interface declaration," and so on.)
As I have been writing formal Ecma specs for new version features, I have (typically) used your suggested approach. That is, to be as precise as possible.
If one were starting from scratch, one would do well to follow your suggestion, but I think that we are way beyond that point, and except in cases where the English-language version isn't precise enough, we can/should change those as we find them.
Given our limited resources, I propose we take no action w.r.t simply cleaning up the existing usage.
BTW, it's not simply a matter of replacing a space with an underscore and making the whole term italic, for something like, "... both a struct and class declaration have ..." would need to be rewritten as "... both a struct_declaration and class_declaration have ...".
I just looked at the JLS to see how how the Java folks deal with this. They seem to never use the (mixed-case) grammar rule name in narrative, but rather, they use the English equivalent without any up-casing.
