D needs a type expression syntax

[Basile B.]

On Thursday, 4 May 2023 at 15:40:20 UTC, Quirin Schroll wrote:
> **TL;DR:** If we make `TypeCtor` optional in the production 
> rule `BasicType` → `TypeCtor`**`(`**`Type`**`)`**, the D type 
> grammar can be improved and we have a way to solve the 
> 14-year-old [issue 
> 2753](https://issues.dlang.org/show_bug.cgi?id=2753).
>
> [...]

Wouldn't making `ref` a TypeCtor solve the issue more simply ?

While using parens is the natural way to disambiguate two 
different constructs, it seems that the only case that causes a 
problem is that we cannot express "return by ref" in function 
types.

With `ref` as a TypeCtor:

     // a function that returns a function ptr that returns an int 
by ref
     ref(int) function(int) makesFPbyRef();
     // function ptr as a parameter type thar returns an int by ref
     void takesFP(ref(int) function() funcPtr)
     // function ptr as a ref parameter type thar returns an int 
by ref
     void takesFP(ref ref(int) function() funcPtr)
     // normal variable type, can be a NOOP or a semantic error
     struct S { ref(int) member; }

That being said, I understand that your proposal is not only 
about the ref issue but to make the grammar for Type nicer.

Then, what is following will be a bit off-topic but, I'd like to 
bring the fact that it might be desirable to keep parens for 
builtin tuples, although it's been a while that the topic was not 
discussed here. In particular a TypeTuple made of a single Type 
would be hard to express properly.