Grammar question. TypeSuffix - what is [ AssignExpression .. AssignExpression ] production for?

[Quirin Schroll]

On Monday, 2 September 2024 at 00:16:14 UTC, WB wrote:
> I am reading D grammar again
>
> and spotted on https://dlang.org/spec/grammar.html#TypeSuffix 
> and https://dlang.org/spec/type.html#grammar
>
> Something weird
>
> ```
> TypeSuffix:
>     *
>     [ ]
>     [ AssignExpression ]
>     [ AssignExpression .. AssignExpression ]
>     [ Type ]
>     delegate Parameters MemberFunctionAttributesopt
>     function Parameters FunctionAttributesopt
> ```
>
> 1st - pointers, 2nd - dynamic arrays, 3rd - static arrays, 5th 
> - associative arrays, 6/7 - delegate types.

Correct.

> The 4th production would mean this is legal (syntactically) 
> variable definition:
>
> ```d
> string[5 .. 9] x;
> ```

Valid syntactically, yes. Valid semantically, of course not.

> My random guess is that this for creating some kind of range 
> checked arrays with non-zero start? I believe languages like 
> Pascal and Ada had similar constructs.

No. If you have a compile-time sequence e.g. generated by 
`AliasSeq!(int, string, bool)`, this rule allows for a sequence 
of locals/parameters to be declared having types of a 
sub-sequence.

> Of course that does not work for any built in type. Nor I see 
> how this could work for user defined type (maybe a static 
> `opSlice` on a user type that creates a proxy object, but that 
> I fails to see how exactly).

It’s not supposed to be used on types, but sequences containing 
types. What comes before the `[l..u]` need not be a type 
semantically, it just must _parse_ as a `BasicType`.

> […]
>
> Could we maybe improve a grammar a bit to make it a bit 
> cleaner, by naming productions?
>
> Something like this:
>
> ```
> TypeSuffix:
>     Pointer
>     Array
>     TypeSequenceSlice
>     FunctionPointer
>     Delegate
> ```
>
> and move existing productions to these sub-rule there 
> accordingly.
>
> Or similar.

No. Production rules that have only one sub-clause are pretty 
much useless. The complete grammar page is not useful for 
understanding the grammar, but for looking up stuff, as you need 
not know which sub-page it’s on. If you want to understand it, 
the specific sub-page should explain it. A grammar entity should 
be named in a meaningful , or at least non-misleading way. I 
changed many names. In fact, [it was me who named it 
`TypeSuffix`](https://github.com/dlang/dlang.org/pull/2873); 
before, it was `BasicType2X`. If we went the route you’re 
suggesting, it would look like this:
```
TypeSuffix:
     Pointer
     Slice
     StaticArray
     AssociativeArray
     SequenceSlice
     CallableSuffix

Pointer:
     *

Slice:
     []

StaticArray:
     [ AssignExpression ]

AssociativeArray:
     [ Type ]

SequenceSlice:
     [ AssignExpression .. AssignExpression ]

CallableSuffix:
     delegate Parameters MemberFunctionAttributes?
     function Parameters FunctionAttributes?
```

The reason for grouping callable suffixes together is that they 
have a lot of similarities. My DIP Draft to allow for `ref` 
returning function pointers and delegates has to single them out. 
The Draft contains a showcase grammar (not actually proposed) 
that does that, too. Now, back to the grammar above: It’s lengthy 
and not really insightful.

I think it’s best to leave some of the grammar to prose and 
explain what things mean in the section below the formal grammar 
box.