On 10/11/20 2:59 PM, Timon Gehr wrote:
> alias x=(t){ return expr; }
> auto x(t){ return expr; }
> 
> Not sure what you are trying to achieve by varying the syntax this way. `=>` or not `=>` has nothing to do with function literal semantics.

You're right, it's already confusing.

I guess we can add more confusion as long as it's added consistently.

-Steve

On 11.10.20 21:07, Steven Schveighoffer wrote:
> On 10/11/20 2:59 PM, Timon Gehr wrote:
>> alias x=(t){ return expr; }
>> auto x(t){ return expr; }
>>
>> Not sure what you are trying to achieve by varying the syntax this way. `=>` or not `=>` has nothing to do with function literal semantics.
> 
> You're right, it's already confusing.
> 
> I guess we can add more confusion as long as it's added consistently.
> 
> -Steve
`auto f(args)=>expr;` being transformed to `auto f(args){ return expr; }` is not confusing. Without the new syntax, the second form is what would occur in the source code, with identical semantics, confusing or not.

No confusion is added.

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.

Thanks! Looking forward to beautifying our projects ;)

At work we already converted one of our projects that was written in C# to use the new syntax about 2 years ago and overall it makes reading and writing code with the new style much more pleasant :)

For more info on this C# feature you can check:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/statements-expressions-operators/expression-bodied-members
https://dotnettutorials.net/lesson/expression-bodied-members-csharp/
https://www.informit.com/articles/article.aspx?p=2414582

On Saturday, 10 October 2020 at 10:18:15 UTC, claptrap wrote:
> From the recent discussions I got the impression that needless syntax sugar shouldn't be added any more.

together

> cause the important thing to me is that my code is simple, readable, expressive

Maybe it's nothing for you, but to me, your second paragraph is exactly the refutation for the first.
It's also about coherence. When lambdas are used, the syntax x => expr is used everywhere when it is admissible, proving their worth.

I do write things like
    int foo(Type param) { return goo(param); }
but only because
    int foo(Type param) => goo(param);
is not admissible.
    int foo(Type param) { return goo(param); }
is not D-style, but
    int foo(Type param)
    {
        return goo(param);
    }
is. Have three of them and they waste significant horizontal space in the source buffer. Every layer of brackets (any kind) in a line adds confusion and hinders our commonly beloved readability. Haskell has weird stuff like the $ operator to deal with Lisp-esque amounts of brackets.

On Sunday, 18 October 2020 at 03:03:32 UTC, Q. Schroll wrote:
> On Saturday, 10 October 2020 at 10:18:15 UTC, claptrap wrote:
>> From the recent discussions I got the impression that needless syntax sugar shouldn't be added any more.
>
> together
>
>> cause the important thing to me is that my code is simple, readable, expressive
>
> Maybe it's nothing for you, but to me, your second paragraph is exactly the refutation for the first.
> It's also about coherence. When lambdas are used, the syntax x => expr is used everywhere when it is admissible, proving their worth.
>
> I do write things like
>     int foo(Type param) { return goo(param); }
> but only because
>     int foo(Type param) => goo(param);
> is not admissible.
>     int foo(Type param) { return goo(param); }
> is not D-style, but
>     int foo(Type param)
>     {
>         return goo(param);
>     }
> is. Have three of them and they waste significant horizontal space in the source buffer. Every layer of brackets (any kind) in a line adds confusion and hinders our commonly beloved readability. Haskell has weird stuff like the $ operator to deal with Lisp-esque amounts of brackets.

To me "readability" is how quickly you can look at some code and understand what it does, not only do i think there's so little difference between those 4 styles that it's irrelevant, I think thats not even code you're going to spend any time looking at.

Also ahem, change the style guide to allow one liners if they are a single statement.

The coherence between features is a better argument, but I'm still meh about about it.

On Saturday, 10 October 2020 at 20:43:55 UTC, Steven Schveighoffer wrote:
> 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".

Agreed. I've filed an enhancement request to make => { } illegal in 2017: https://issues.dlang.org/show_bug.cgi?id=17951
It's a long-standing hurdle for newcomers and nobody really needs double delegates of this form on such a regular basis that such a hurdle for newcomers is justified.