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.

The 4th production would mean this is legal (syntactically) variable definition:

string[5 .. 9] x;

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.

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).

Any idea what is this [ AssignExpression .. AssignExpression ] production for actually?

Is it for some tuple / type sequence slicing? (I guess it is called AliasSeq in current Phobos)

However, in places like https://dlang.org/library/std/meta/alias_seq.html I cannot see this being mentioned (second example kind of hints at it tho).

I also looked at https://dlang.org/spec/function.html#d_style_variadic_functions for D-style variadic functions, but I think it is not that.

So maybe https://dlang.org/spec/template.html#variadic-templates , where more specifically https://dlang.org/spec/template.html#seq-ops mentions slicing operation on these sequences ?

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.

On Monday, 2 September 2024 at 00:16:14 UTC, WB wrote:

TypeSuffix:
    *
    [ ]
    [ AssignExpression ]
    [ AssignExpression .. AssignExpression ]
    [ Type ]
    delegate Parameters MemberFunctionAttributesopt
    function Parameters FunctionAttributesopt

string[5 .. 9] x;

import std.meta: AliasSeq;

alias MyTypes = AliasSeq!(int, double, string);

MyTypes[1 .. 3] myVars;
static assert(is(typeof(myVars[0]) == double));
static assert(is(typeof(myVars[1]) == string));

On Monday, 2 September 2024 at 00:16:14 UTC, WB wrote:

Good docs for what seq does, doesnt exist; period. You have to learn from trail and error.

That would be the correct place to link to something and Ive suggested that d3 std.meta links to the template book as a bandaid, but I dont think it will happen, nor do I think anyone is going to work on writing out the fundmental operations you have for seq's.

On Monday, 2 September 2024 at 16:35:11 UTC, monkyyy wrote:

What's wrong with:

On Wednesday, 4 September 2024 at 17:31:53 UTC, Nick Treleaven wrote:

What OP wants (I believe) is that:

TypeNext:
    TypeStaticArray
    TypeStaticSlice
    TypeSequenceSlice
    ...
    BasicType

TypeStaticArray:
    TypeNext [ AssignExpression ]

TypeSlice:
    TypeNext [ ]


TypeSequenceSlice:
    TypeNext [ AssignExpression .. AssignExpression ]

So that the doc for https://dlang.org/spec/type.html could work similarly to
https://dlang.org/spec/declaration.html, i.e each construct can have its own grammar div. Actually types-docs feel a bit sub-standard compared to.

On Wednesday, 4 September 2024 at 17:31:53 UTC, Nick Treleaven wrote:

Seq's are builtin data types that need more explanations then aa's and slices, lets assume you realized that the spec is useless and went to the book for slices you get 3 pages worth of code examples for whats not that hard to understand. The spec only offers 3 code examples, none of which covers, oh, lets say static foreach of seq's, youd need to know to go to spec on foreach to look for it.

The template book should be "made cannon" and probably get some major updates(it is after all, 10 years out of date).

On Wednesday, 4 September 2024 at 19:21:21 UTC, monkyyy wrote:

It's a spec, so it links to foreach on a sequence (which has examples):

On Monday, 2 September 2024 at 00:16:14 UTC, WB wrote:

TypeSuffix:
    *
    [ ]
    [ AssignExpression ]
    [ AssignExpression .. AssignExpression ]
    [ Type ]
    delegate Parameters MemberFunctionAttributesopt
    function Parameters FunctionAttributesopt

Correct.

string[5 .. 9] x;

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

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.

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.

TypeSuffix:
    Pointer
    Array
    TypeSequenceSlice
    FunctionPointer
    Delegate

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; 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.

On Thursday, 5 September 2024 at 14:22:56 UTC, Quirin Schroll wrote:

Thanks!

A type sequence can be indexed, so calling it StaticArray would be confusing.

...

+1

On Thursday, 5 September 2024 at 19:32:52 UTC, Nick Treleaven wrote:

Of course. I missed that. Another reason not to name it!