proposal: short => rewrite for function declarations

claptrap clap at trap.com
Sun Oct 18 10:08:20 UTC 2020


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.


More information about the Digitalmars-d mailing list