D needs a type expression syntax

[Nick Treleaven]

On Thursday, 4 May 2023 at 15:40:20 UTC, Quirin Schroll wrote:
> ref int refId   (ref int i) => i;
> ref int function(ref int i) refIdPtr = &refId; // Doesn’t parse!
> ```
> You can declare `refIdPtr` with `auto` because the type of 
> `&refId` is 100 % well-formed, it’s just a syntax issue 
> spelling it out in code; if you `pragma(msg, typeof(refIdPtr))` 
> you get:
> ```d
> int function(ref int i) ref
> ```
> Interesting where the `ref` is, isn’t it? Go ahead, try using 
> *that* instead of `auto`. It doesn’t parse! And frankly, it 
> shouldn’t; it’s confusing to read.

It could be trailing return type syntax:
```d
function(ref int i) -> ref int refIdPtr;
```
Then we don't need the `alias A = ref T` rule, and we can keep 
parentheses for expressions (including tuples in future).

Trailing return is much easier to read, when you read a function 
signature the return type is not as salient as the name or the 
parameter list (particularly as there's no overloading by return 
type). The return type gets in the way, especially when its a 
complex type:
```
some_package.Foo!(const(ElementType!R)[]) oh_hi(long parameter, 
list following)
```
Some people also recommend putting attributes after the parameter 
list rather than before the declaration for this reason.

Imagine in an IDE seeing a list of function overloads, if they 
were shown with trailing return syntax it would be much easier to 
find the overload you want.

> ```d
>  const Object  function()  f0; // Make this an error …
> const (Object  function()) f1; // … and require this!
> (const Object) function()  f2; // To differentiate from this.
>  const(Object) function()  f3; // (Same type as f2)
> ```

I don't get what the issue is with f0 and f3, aren't they clear 
enough?

> We should do the same for type constructors as storage classes 
> for non-static member function when used in front of the 
> declaration:
> ```d
> struct S
> {
>     const void action() { } // Make this an error …
>     void action() const { } // … and require this!
> }
> ```
> D requires `ref` on the front, why should we have an issue with 
> requiring that type constructors go to the end?

Amen, we should have done this long ago IMO. A needless hindrance 
for those learning D.