October 09, 2020
On Friday, 9 October 2020 at 19:11:44 UTC, Steven Schveighoffer wrote:
> You aren't saving much though, I do a lot of one-liners like:

Yeah, but we could (and did) say the same thing about the other uses of the => syntax. It was accepted there, so this just makes it consistently allowed in more cases.

> Which is super-useful and less verbose. But in this syntax, I'm guessing it's going to interpret v as a type?

Right, it will complain "undefined identifier", same as if you wrote it `whatever foo(v) { return stuff; }`. As you can see from the PR diff, there's no special cases, just a straight forward syntax shortcut to keep it simple.

Of course you can still do:

auto identity(T)(T a) => a;

if you wanted to.
October 10, 2020
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.

From the recent discussions I got the impression that needless syntax sugar shouldn't be added any more. To get new features in it needs to be something that cant be done with existing language features, or it needs to fix something.

So doesn't this just add more "stuff" for no meaningful benefit?

I couldnt care less about

@property x() => _x;

vs

@property x() { return -x; }

cause the important thing to me is that my code is simple, readable, expressive, i dont care about saving 7 chars on a one liner.


October 10, 2020
On Saturday, 10 October 2020 at 10:18:15 UTC, claptrap wrote:
> 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.
>
> From the recent discussions I got the impression that needless syntax sugar shouldn't be added any more. To get new features in it needs to be something that cant be done with existing language features, or it needs to fix something.
>
> So doesn't this just add more "stuff" for no meaningful benefit?
>
> I couldnt care less about
>
> @property x() => _x;
>
> vs
>
> @property x() { return -x; }
>
> cause the important thing to me is that my code is simple, readable, expressive, i dont care about saving 7 chars on a one liner.

I assume, if you follow the style guide, the second example should be written with 4 lines:

@property x()
{
    return -x;
}

While the proposal from Adam is a 1 liner also from a style guide perspective:

@property x() => _x;

(Yes, this is nitpicking... but for me the reason why I like the proposal).

Kind regards
Andre



October 10, 2020
On Saturday, 10 October 2020 at 10:18:15 UTC, claptrap wrote:
> On Friday, 9 October 2020 at 14:44:25 UTC, Adam D. Ruppe wrote:
>> [...]
>
> From the recent discussions I got the impression that needless syntax sugar shouldn't be added any more. To get new features in it needs to be something that cant be done with existing language features, or it needs to fix something.
>
> So doesn't this just add more "stuff" for no meaningful benefit?
>
> I couldnt care less about
>
> @property x() => _x;
>
> vs
>
> @property x() { return -x; }
>
> cause the important thing to me is that my code is simple, readable, expressive, i dont care about saving 7 chars on a one liner.

What do you mean. It removes stuff. I'd say Adam's proposal is more readable.
October 10, 2020
On Saturday, 10 October 2020 at 12:30:24 UTC, Imperatorn wrote:
>
> What do you mean. It removes stuff. I'd say Adam's proposal is more readable.

I don't experience it as more readable. However, the biggest problem I have with it is that we just add more ways doing the same thing. I want the D should be restrictive adding more ways doing the same thing, otherwise we will get into a C++ situation. Initialization in C++, has more different ways than you can count on your fingers.
October 10, 2020
On Saturday, 10 October 2020 at 12:30:24 UTC, Imperatorn wrote:

>>
>> @property x() => _x;
>>
>> vs
>>
>> @property x() { return -x; }
>>
>> cause the important thing to me is that my code is simple, readable, expressive, i dont care about saving 7 chars on a one liner.
>
> What do you mean. It removes stuff. I'd say Adam's proposal is more readable.

Not to me. Taking away the braces and the return statement turns it into a foreign language.
October 10, 2020
On Saturday, 10 October 2020 at 12:36:15 UTC, IGotD- wrote:
> On Saturday, 10 October 2020 at 12:30:24 UTC, Imperatorn wrote:
>>
>> What do you mean. It removes stuff. I'd say Adam's proposal is more readable.
>
> I don't experience it as more readable. However, the biggest problem I have with it is that we just add more ways doing the same thing. I want the D should be restrictive adding more ways doing the same thing, otherwise we will get into a C++ situation. Initialization in C++, has more different ways than you can count on your fingers.

Sure, readability is subjective. It's shorter though. And I agree that we generally should be very restrictive with adding features. But I believe this would be achieved through a preview switch, so technically it doesn't change the default case.
October 10, 2020
On Saturday, 10 October 2020 at 13:05:48 UTC, Mike Parker wrote:
> On Saturday, 10 October 2020 at 12:30:24 UTC, Imperatorn wrote:
>
>>>
>>> @property x() => _x;
>>>
>>> vs
>>>
>>> @property x() { return -x; }
>>>
>>> cause the important thing to me is that my code is simple, readable, expressive, i dont care about saving 7 chars on a one liner.
>>
>> What do you mean. It removes stuff. I'd say Adam's proposal is more readable.
>
> Not to me. Taking away the braces and the return statement turns it into a foreign language.

Might be a bit of a stretch to say it becomes a "foreign language" just because you change one thing... But, I do agree that in general you should be very restrictive about adding things. A new feature always seems so nice and shiny in the beginning, before you have analysed its potential side effects.
October 10, 2020
On Saturday, 10 October 2020 at 13:55:13 UTC, Imperatorn wrote:
> On Saturday, 10 October 2020 at 13:05:48 UTC, Mike Parker wrote:
>> On Saturday, 10 October 2020 at 12:30:24 UTC, Imperatorn wrote:
>>
>>>>
>>>> @property x() => _x;
>>>>
>>>> vs
>>>>
>>>> @property x() { return -x; }
>>>>
>>>> cause the important thing to me is that my code is simple, readable, expressive, i dont care about saving 7 chars on a one liner.
>>>
>>> What do you mean. It removes stuff. I'd say Adam's proposal is more readable.
>>
>> Not to me. Taking away the braces and the return statement turns it into a foreign language.
>
> Might be a bit of a stretch to say it becomes a "foreign language" just because you change one thing... But, I do agree that in general you should be very restrictive about adding things. A new feature always seems so nice and shiny in the beginning, before you have analysed its potential side effects.

It's a question of point of view.
This is not adding a new feature, it's removing a restriction. The lambdas (i.e. unnamed functions) have 2 possible syntaxes. Named functions have only 1. This is inconsistent. Removing the second syntax from lambdas is not possible (unending breakage) so it is more logic to remove the syntax restriction from named functions. As shown it is a very simple change and it removes an artificial restriction.
It is clear that dubious languages and syntax additions are to be avoided but this ain't any of it.
October 10, 2020
On Saturday, 10 October 2020 at 13:05:48 UTC, Mike Parker wrote:
> On Saturday, 10 October 2020 at 12:30:24 UTC, Imperatorn wrote:
>
>>>
>>> @property x() => _x;
>>>
>>> vs
>>>
>>> @property x() { return -x; }
>>>
>>> cause the important thing to me is that my code is simple, readable, expressive, i dont care about saving 7 chars on a one liner.
>>
>> What do you mean. It removes stuff. I'd say Adam's proposal is more readable.
>
> Not to me. Taking away the braces and the return statement turns it into a foreign language.

It's literally how lambda's are defined.

auto x = () => _x; // no return statement, no braces
auto x = () { return _x; }; // exactly the same