proposal: short => rewrite for function declarations

Steven Schveighoffer schveiguy at gmail.com
Sat Oct 10 20:43:55 UTC 2020


On 10/10/20 2:53 PM, Ola Fosheim Grøstad wrote:
> On Saturday, 10 October 2020 at 16:38:56 UTC, Sebastiaan Koppe wrote:
>> Obvious addition, don't understand much of the resistance. My 
>> experience is that a lot of languages use => similarly.
> 
> I assume that TypeScript and Dart allows "=> expr" as a shortcut for 
> "{return expr;}" on method bodies. So some programmers might expect it, 
> yes.

In JavaScript (TypeScript), it looks like => {return expr} and yes, just 
giving an expression is short for that.

I think if D is going to go this route, it needs to at least get rid of 
the ambiguity of => {return expr;}, which is currently "return a 
delegate/function that returns expr".

> Having many ways to express methods make code harder to read IMO, but if 
> is in the language already then it makes sense to make it a proper 
> shortcut and not a special case.

I'm not 100% against it, though I don't see a need for it. But one of 
the biggest sticking points I have is:

struct v
{
   static int foo;
}

1. (v) => v.foo;
2. auto x(v) => v.foo;

The differences here:

1. is short for:
(T)(T v) {
   return v.foo;
}

2. is short for:

auto x(v _param0) {
   return v.foo;
}

This is quite a different set of rules for parameter names and types.

I would say that for shortened syntax for declarations, you cannot 
specify parameters with no names to avoid ambiguity. e.g. you would have 
to do:

auto x(v unused) => v.foo;

-Steve


More information about the Digitalmars-d mailing list