• Quirin Schroll (58/58) Sep 24 The grammar of
• Kagamin (3/3) Sep 25 I suppose it's done to simplify grammar. One concept less.
• Quirin Schroll (7/10) Sep 26 I actually implemented the base class thing already.

Quirin Schroll <qs.il.paperinik gmail.com> writes:

The grammar of 
[`ClassDeclaration`](https://dlang.org/spec/class.html#ClassDeclaration) allows
the base class and interface specification to be an arbitrary
[`BasicType`](https://dlang.org/spec/type.html#BasicType).

Now, that is quite obviously because `BasicType` allows it to be 
any of the following:
```
BasicType:
   FundamentalType
   . QualifiedIdentifier
   QualifiedIdentifier
   Typeof
   Typeof . QualifiedIdentifier
   TypeCtor ( Type )
   Vector
   TraitsExpression
   MixinType
```

It is clear why we would want to allow most of those. The only 
two exceptions are:
* `TypeCtor ( Type )`
* `Vector`

In practice, `Vector` is no big deal. It’s for `__vector` 
extensions and those can’t be bases anyway. The annoying one is 
`TypeCtor ( Type )`. In the end, what’s in parentheses is 
equivalent to being used directly. This is about parsing, i.e. 
written code, so if you had e.g. `: const(Something)` in your 
codebase, you could just use `: Something`. It’s not about 
aliases or `typeof`s that evaluate to `const(Something)`.

I’d propose to deprecate or even outright remove/ban `TypeCtor ( 
Type )` as a base class / interface. It’s nonsensical and 
confusing.

Tim made me aware of this [this 
post](https://forum.dlang.org/post/gitxzhsdymuehuakdvew forum.dlang.org). If my
upcoming Primary Type Syntax DIP is accepted, it’ll change `BasicType` to
make the `TypeCtor` optional, i.e. `( Type )` would be a `BasicType`, and in a
`new class` expression, that would lead to ambiguities between the argument
list (passed to the constructor of the anonymous class) and the base class /
interface list of the anonymous class.

It would be a little disruptive to the grammar, but one way to do 
it is to introduce a distinction between `PrimaryType` and 
`BasicType`, and replace all but few mentions of `BasicType` by 
`PrimaryType`.
```
PrimaryType:
   BasicType
   TypeCtor ( Type )
   Vector

BasicType:
   FundamentalType
   . QualifiedIdentifier
   QualifiedIdentifier
   Typeof
   Typeof . QualifiedIdentifier
   TraitsExpression
   MixinType
```

Also, `Vector` should probably just be replaced by `__vector ( 
PrimaryType TypeSuffixes? )` with the mention that the 
`PrimaryType TypeSuffixes?` must evaluate to a static array type. 
Also, type qualifiers should not be allowed (lexically), as 
they’re ignored, e.g. `__vector(const int[4])` is another way to 
spell `__vector(int[4])`. In general, the `Vector` grammar is 
very flexible, and I wonder why and how it could be narrowed 
down, but on the other hand, I actually don’t care much.

Kagamin <spam here.lot> writes:

I suppose it's done to simplify grammar. One concept less. 
Something similar was reported in bugzilla: the reporter wanted 
to syntactically disallow `this` in static methods.

Quirin Schroll <qs.il.paperinik gmail.com> writes:

On Thursday, 26 September 2024 at 06:48:12 UTC, Kagamin wrote:
 I suppose it's done to simplify grammar. One concept less. 
 Something similar was reported in bugzilla: the reporter wanted 
 to syntactically disallow `this` in static methods.

I actually implemented the base class thing already.

Those are vastly different spaces.

Not having `this` as a syntactically valid token in a non-member 
function makes little sense. Imagine writing mixin templates 
without having `typeof(this)`.

Also, the grammar defines a lot of rather useless entities.