Thread overview
Do you use full-on BasicType base class / interface?
Sep 26
Kagamin
September 24

The grammar of ClassDeclaration allows the base class and interface specification to be an arbitrary 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 typeofs 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. 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.

September 26

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.

September 26

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.