From this post:

http://adamralph.com/2013/12/06/ndc-diary-day-3/?1

Seems C# will gain this syntax:

public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);

That means:

public Point Move(int dx, int dy) { return new Point(X + dx, Y + dy); }

Even Ada2012 has a similar syntax. I think it's worth having in D.

The ER:
https://d.puremagic.com/issues/show_bug.cgi?id=7176

Bye,
bearophile

On Saturday, 7 December 2013 at 17:29:43 UTC, bearophile wrote:
> public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
>
> That means:
>
> public Point Move(int dx, int dy) { return new Point(X + dx, Y + dy); }

Maybe It's just me, but on the example above I don't see too much improvement:

1 word off ("return"), and "=>" instead of brackets.

Sorry I forgot one thing:

On this code:

public Point Move(int dx, int dy) { return new Point(X + dx, Y +
dy); }

It would be too much trouble if the language automatically return the last statement if this was the same type of the method? For example:

public Point Move(int dx, int dy){
    new Point(X + dx, Y + dy);
}

The return keyword wouldn't needed to be declared, because the statement is a Point type which is the same type that method returns.

Something like for example what happens in LISP, which returns the last statement by default.

MattCoder:

> Maybe It's just me, but on the example above I don't see too much improvement:
>
> 1 word off ("return"), and "=>" instead of brackets.

In D:

Point move(in int dx, in int dy) pure nothrow {
    return Point(X + dx, Y + dy);
}

Point move(in int dx, in int dy) pure nothrow => Point(X + dx, Y + dy);

It saves you almost 10% of typing, and makes more visible that move is an expression. If you use UFCS chains a lot, many functions become small and they sometimes contain just an expression.

Currently in D you can write:

enum move = (in int dx, in int dy) pure nothrow => Point(X + dx, Y + dy);

But here you can't specify the return value, this sometimes is a problem, because you miss the implicit cast at the return point (char[] -> string in pure functions, char -> dchar, Point -> const(Point), etc).

Bye,
bearophile

On Saturday, 7 December 2013 at 18:13:06 UTC, bearophile wrote:
> MattCoder:
>
>> Maybe It's just me, but on the example above I don't see too much improvement:
>>
>> 1 word off ("return"), and "=>" instead of brackets.
>
> In D:
>
> Point move(in int dx, in int dy) pure nothrow {
>     return Point(X + dx, Y + dy);
> }
>
> Point move(in int dx, in int dy) pure nothrow => Point(X + dx, Y + dy);
>
> It saves you almost 10% of typing, and makes more visible that move is an expression. If you use UFCS chains a lot, many functions become small and they sometimes contain just an expression.

Well,I think you have a point here.

> Currently in D you can write:
>
> enum move = (in int dx, in int dy) pure nothrow => Point(X + dx, Y + dy);

Interesting, I didn't know about this. Thanks for the tip.

Matheus.

On Saturday, 7 December 2013 at 17:43:46 UTC, MattCoder wrote:
> On Saturday, 7 December 2013 at 17:29:43 UTC, bearophile wrote:
>> public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
>>
>> That means:
>>
>> public Point Move(int dx, int dy) { return new Point(X + dx, Y + dy); }
>
> Maybe It's just me, but on the example above I don't see too much improvement:
>
> 1 word off ("return"), and "=>" instead of brackets.

You've pretty much just summed up the argument not to introduce lambda syntax. It has been proven wrong.

On 12/07/2013 07:13 PM, bearophile wrote:
>
> Currently in D you can write:
>
> enum move = (in int dx, in int dy) pure nothrow => Point(X + dx, Y + dy);

IIRC Don said this shouldn't work since the context is not actually known at compile time.

Timon Gehr:

> IIRC Don said this shouldn't work since the context is not actually known at compile time.

I remember Don saying similar things on some other usages of 'enum'. If all this needs to become accepts-invalid errors, then dmd 2.065 seems a good moment to fix this messy situation. Suggestions from Walter/Andrei are welcome.

Bye,
bearophile

Am Sat, 07 Dec 2013 21:21:03 +0100
schrieb "Jesse Phillips" <Jesse.K.Phillips+D@gmail.com>:

> On Saturday, 7 December 2013 at 17:43:46 UTC, MattCoder wrote:
> > On Saturday, 7 December 2013 at 17:29:43 UTC, bearophile wrote:
> >> public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
> >>
> >> That means:
> >>
> >> public Point Move(int dx, int dy) { return new Point(X + dx, Y + dy); }
> >
> > Maybe It's just me, but on the example above I don't see too much improvement:
> >
> > 1 word off ("return"), and "=>" instead of brackets.
>
> You've pretty much just summed up the argument not to introduce lambda syntax. It has been proven wrong.

I think it is a good middle ground for predicates where I
don't like to use strings mixins instead of plain expressions:
  "a > b"
But the verbose D syntax is just too distracting:
  bool function(T a, T b) { return a > b; })
lambdas on the other hand save a lot of typing and have first
class language support:
  (a, b) => a > b
If some day we can omit the parameter list like in some other
language, I wouldn't mind.

-- 
Marco

The relative Reddit thread explains another small feature of the next C#:

http://www.reddit.com/r/programming/comments/1sbkxl/a_quick_highlight_of_upcoming_c_language_changes/cdwedrh


If I understand that, it's similar to allowing D code like this:


bool foo(out int x) {
    x = 10;
    return true;
}
void main() {
    if (foo(int y))
        y.writeln;
}


Currently in D you have to write:

void main() {
    int y;
    if (foo(y))
        y.writeln;
}

Bye,
bearophile