October 10, 2020
On Saturday, 10 October 2020 at 12:30:24 UTC, Imperatorn wrote:
> 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.

How quickly you can visually parse either of them is probably 99% down to what your used to. And even then the difference will be minuscule. So it's completely irrelevant imo.









October 10, 2020
On Saturday, 10 October 2020 at 10:25:05 UTC, Andre Pany wrote:
> 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:
>>
> 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).

A better solution is to modify the style guide to allow one liners where reasonable..

And you can just ignore it till then. :)
October 10, 2020
On 09.10.20 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.
> 
> See more in the PR description and the test case there.

https://issues.dlang.org/show_bug.cgi?id=7176

(I have wanted this many times, it's an arbitrary limitation.)
October 10, 2020
On Saturday, 10 October 2020 at 13:55:13 UTC, Imperatorn wrote:

> Might be a bit of a stretch to say it becomes a "foreign language" just because you change one thing...

What I mean is that my brain is conditioned to see the braces and the return statement. I recognize everything immediately and don't have to think about it. If I'm scanning D code and I see the shorthand lambda syntax for delegates, I have to stop and think about it. So yeah, to me, it's like a foreign language.
October 10, 2020
On Saturday, 10 October 2020 at 15:11:16 UTC, Mike Parker wrote:
> On Saturday, 10 October 2020 at 13:55:13 UTC, Imperatorn wrote:
>
>> Might be a bit of a stretch to say it becomes a "foreign language" just because you change one thing...
>
> What I mean is that my brain is conditioned to see the braces and the return statement. I recognize everything immediately and don't have to think about it. If I'm scanning D code and I see the shorthand lambda syntax for delegates, I have to stop and think about it. So yeah, to me, it's like a foreign language.

Well ok, I guess "foreign" because it's not in the language atm. Sure. But not foreign as in "I don't understand". That's quite different.
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
>
> One benefit is shorter property accessors:
>
>     private int _x = 34;
>     @property x() => _x;
>     @property x(int v) => _x = v;
>
> So it just extends the existing lambda shorthand to full declarations too.

Obvious addition, don't understand much of the resistance. My experience is that a lot of languages use => similarly.
October 10, 2020
On 10/10/20 6:25 AM, Andre Pany wrote:
> 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).
> 

The D style guide is here:

https://dlang.org/dstyle.html

Indeed, it says you should always use separate lines for braces for all functions. But I think even Phobos/Druntime don't always follow this convention. We should change it so property functions and/or simple "return exp" functions do not need to be multiple lines.

This is not a reason to accept a language change, at all. Just change the style guide.

-Steve
October 10, 2020
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.

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.


October 10, 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
October 10, 2020
On Saturday, 10 October 2020 at 20:43:55 UTC, Steven Schveighoffer wrote:
> This is quite a different set of rules for parameter names and types.

That would be more difficult for newbies than not having => for member functions at all...

I think this would be something that you can transpile as an upgrade though. E.g. compiler ships with source-to-source transform.