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