Thread overview | ||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
October 09, 2020 proposal: short => rewrite for function declarations | ||||
---|---|---|---|---|
| ||||
After a brief chat yesterday, I slapped this together: https://github.com/dlang/dmd/pull/11833 In short, in a function declaration, it rewrites `=> ...;` into `{ return ...; }` One benefit is shorter property accessors: private int _x = 34; @property x() => _x; @property x(int v) => _x = v; But it also works basically anywhere bool isNull() => this is null; auto identity(T)(T a) => a; @property y() in(true) => _x; // contracts still work too So it just extends the existing lambda shorthand to full declarations too. See more in the PR description and the test case there. |
October 09, 2020 Re: proposal: short => rewrite for function declarations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Friday, 9 October 2020 at 14:44:25 UTC, Adam D. Ruppe wrote:
> After a brief chat yesterday, I slapped this together:
>
> https://github.com/dlang/dmd/pull/11833
>
> In short, in a function declaration, it rewrites `=> ...;` into `{ return ...; }`
>
> One benefit is shorter property accessors:
>
> private int _x = 34;
> @property x() => _x;
> @property x(int v) => _x = v;
>
> But it also works basically anywhere
>
> bool isNull() => this is null;
> auto identity(T)(T a) => a;
> @property y() in(true) => _x; // contracts still work too
>
> So it just extends the existing lambda shorthand to full declarations too.
>
> See more in the PR description and the test case there.
This needs a dip and a preview switch. I was working on a dip that makes @property useful in the discord chat, and then you go off and implement one of the syntax that we had talk about.
Alex
|
October 09, 2020 Re: proposal: short => rewrite for function declarations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On 2020-10-09 16:44, Adam D. Ruppe wrote: > After a brief chat yesterday, I slapped this together: > > https://github.com/dlang/dmd/pull/11833 > > In short, in a function declaration, it rewrites `=> ...;` into `{ return ...; }` > > One benefit is shorter property accessors: > > private int _x = 34; > @property x() => _x; > @property x(int v) => _x = v; > > But it also works basically anywhere > > bool isNull() => this is null; > auto identity(T)(T a) => a; > @property y() in(true) => _x; // contracts still work too > > So it just extends the existing lambda shorthand to full declarations too. Yes please. -- /Jacob Carlborg |
October 09, 2020 Re: proposal: short => rewrite for function declarations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Friday, 9 October 2020 at 14:44:25 UTC, Adam D. Ruppe wrote:
> After a brief chat yesterday, I slapped this together:
>
> https://github.com/dlang/dmd/pull/11833
>
> In short, in a function declaration, it rewrites `=> ...;` into `{ return ...; }`
>
> One benefit is shorter property accessors:
>
> private int _x = 34;
> @property x() => _x;
> @property x(int v) => _x = v;
>
> But it also works basically anywhere
>
> bool isNull() => this is null;
> auto identity(T)(T a) => a;
> @property y() in(true) => _x; // contracts still work too
>
> So it just extends the existing lambda shorthand to full declarations too.
>
> See more in the PR description and the test case there.
If I remember correctly, the property setter in your example works, because the assignment _x = v returns an int.
In case you do not assign the value but call a method which has return type void, it won't work? (As far as I remember).
Overall I like your proposal.
Kind regards
Andre
|
October 09, 2020 Re: proposal: short => rewrite for function declarations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andre Pany | On Friday, 9 October 2020 at 17:40:56 UTC, Andre Pany wrote:
> If I remember correctly, the property setter in your example works, because the assignment _x = v returns an int.
> In case you do not assign the value but call a method which has return type void, it won't work? (As far as I remember).
Well, it will actually sometimes work.
Remember it just rewrites => x; into { return x; } And dmd *sometimes* lets you:
void foo() {}
void test() {
return foo();
}
It sees you are just returning void from a void function and allows it.
If it is allowed there,
void test() => foo();
is also allowed.
But `void b() => _x = 5;` triggers "Error: cannot return non-void from void function", the same as if you wrote out `void b() { return _x = 5; }`
If you don't want to return anything of course you can just write the bracket syntax:
// this is allowed, but why would you when you can just write...
void foo() => cast(void)(x+=5);
// this instead?
void foo() { x+= 5; }
You only really save syntax if you are returning something anyway.
|
October 09, 2020 Re: proposal: short => rewrite for function declarations | ||||
---|---|---|---|---|
| ||||
Posted in reply to 12345swordy | On Friday, 9 October 2020 at 14:46:28 UTC, 12345swordy wrote:
> I was working on a dip that makes @property
This works with @property of course, but it is not specific to it in any way. It might even help your dip.
|
October 09, 2020 Re: proposal: short => rewrite for function declarations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Friday, 9 October 2020 at 17:50:54 UTC, Adam D. Ruppe wrote:
> On Friday, 9 October 2020 at 17:40:56 UTC, Andre Pany wrote:
>> [...]
>
> Well, it will actually sometimes work.
>
> Remember it just rewrites => x; into { return x; } And dmd *sometimes* lets you:
>
> [...]
Thanks for the explanation, makes sense.
Kind regards
Andre
|
October 09, 2020 Re: proposal: short => rewrite for function declarations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Friday, 9 October 2020 at 14:44:25 UTC, Adam D. Ruppe wrote: > After a brief chat yesterday, I slapped this together: > > https://github.com/dlang/dmd/pull/11833 > > In short, in a function declaration, it rewrites `=> ...;` into `{ return ...; }` > Very much support! (a limited form of) This is widely used in ECMAscript and called "arrow function" https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions |
October 09, 2020 Re: proposal: short => rewrite for function declarations | ||||
---|---|---|---|---|
| ||||
Posted in reply to James Blachly | On Friday, 9 October 2020 at 18:09:38 UTC, James Blachly wrote:
> (a limited form of) This is widely used in ECMAscript and called "arrow function"
Yeah, D already has it very similarly to that too, you can use it for function arguments and variables, just not in like class definitions, so it was a small change to the compiler to add it here.
|
October 09, 2020 Re: proposal: short => rewrite for function declarations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On 10/9/20 10:44 AM, Adam D. Ruppe wrote:
> After a brief chat yesterday, I slapped this together:
>
> https://github.com/dlang/dmd/pull/11833
>
> In short, in a function declaration, it rewrites `=> ...;` into `{ return ...; }`
>
> One benefit is shorter property accessors:
>
> private int _x = 34;
> @property x() => _x;
> @property x(int v) => _x = v;
>
> But it also works basically anywhere
>
> bool isNull() => this is null;
> auto identity(T)(T a) => a;
> @property y() in(true) => _x; // contracts still work too
>
> So it just extends the existing lambda shorthand to full declarations too.
>
> See more in the PR description and the test case there.
It's kind of weird. You usually name a lambda outside the definition. Like:
auto x = () => _x;
But having the name makes it unambiguous from an actual lambda. You aren't saving much though, I do a lot of one-liners like:
@property x() { return _x; }
Compare to:
@property x() => _x;
It's not *that* much savings...
A lambda can also have no type for the parameter:
(v) => _x + v;
(T)(T v) => _x + v; // equivalent to this
Which is super-useful and less verbose. But in this syntax, I'm guessing it's going to interpret v as a type?
-Steve
|
Copyright © 1999-2021 by the D Language Foundation