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