Hello all (: This is my first post here.

I don't know if this has been proposed before. Probably, it has been. Either way...

https://github.com/dotnet/roslyn/wiki/New-Language-Features-in-C%23-6#expression-bodied-function-members

Given D's tendency toward expression-oriented (or functional, whatever) programming, this seems like a logical addition to the language to me.

Cheers.

On 12/31/2015 06:15 PM, Gabriel Garcia wrote:
> Hello all (: This is my first post here.
>
> I don't know if this has been proposed before. Probably, it has been.
> Either way...
>
> https://github.com/dotnet/roslyn/wiki/New-Language-Features-in-C%23-6#expression-bodied-function-members
>
>
> Given D's tendency toward expression-oriented (or functional, whatever)
> programming, this seems like a logical addition to the language to me.
>
> Cheers.

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

On Thursday, 31 December 2015 at 17:46:16 UTC, Timon Gehr wrote:
> On 12/31/2015 06:15 PM, Gabriel Garcia wrote:
>> Hello all (: This is my first post here.
>>
>> I don't know if this has been proposed before. Probably, it has been.
>> Either way...
>>
>> https://github.com/dotnet/roslyn/wiki/New-Language-Features-in-C%23-6#expression-bodied-function-members
>>
>>
>> Given D's tendency toward expression-oriented (or functional, whatever)
>> programming, this seems like a logical addition to the language to me.
>>
>> Cheers.
>
> https://issues.dlang.org/show_bug.cgi?id=7176

I would really like to see this moving forward. What would it take? A PR on GitHub? The attached Proof of Concept seems like a decent start. I am not familiar at all with the codebase, though the patch is quite small and understandable. If nobody with actual credentials or experience steps up in the coming days/weeks, I suppose I could give it a try.

FWIW, I've given the issue 20 votes.

On Thursday, 31 December 2015 at 19:52:25 UTC, Gabriel Garcia wrote:
> I would really like to see this moving forward. What would it take?

First off you would have to convince the language maintainers that it's a good idea. I see two major contributors, Kenji Hara and Jonathan M Davis, are against it in that thread.

On Thursday, 31 December 2015 at 17:15:16 UTC, Gabriel Garcia wrote:
> Hello all (: This is my first post here.
>
> I don't know if this has been proposed before. Probably, it has been. Either way...
>
> https://github.com/dotnet/roslyn/wiki/New-Language-Features-in-C%23-6#expression-bodied-function-members
>
> Given D's tendency toward expression-oriented (or functional, whatever) programming, this seems like a logical addition to the language to me.
>
> Cheers.

By the way, a very similar language feature was approved and implemented for the upcomming DMD 2.070 release. It allows you to use a short syntax for function templates:

alias add = (a, b) => a + b;
// Shorthand for:
// auto add(T1, T2)(T1 a, T2 b) { return a + b; }

IFTI makes it look like a regular function call:
writeln(add(3, 4.5));

It works for free functions, but I'm not sure if it would also work for member-functions (methods).

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

http://dlang.org/spec/declaration.html#AliasDeclaration
(The relevant part is:
AliasDeclarationY:
    Identifier TemplateParametersopt = FunctionLiteral)

https://github.com/D-Programming-Language/dmd/commit/dbba59cadafe540c0c98d69ac867173335e145cd

On Friday, 1 January 2016 at 00:27:49 UTC, ZombineDev wrote:
> By the way, a very similar language feature was approved and implemented for the upcomming DMD 2.070 release. It allows you to use a short syntax for function templates:
>
> alias add = (a, b) => a + b;
> // Shorthand for:
> // auto add(T1, T2)(T1 a, T2 b) { return a + b; }
>
> IFTI makes it look like a regular function call:
> writeln(add(3, 4.5));
>
> It works for free functions, but I'm not sure if it would also work for member-functions (methods).
>
> https://issues.dlang.org/show_bug.cgi?id=12421

IMHO, anything like that is just a tangential 'fix' to the fact that D's design rests on commands like 'return' to leave scope and return values.

Something like

auto add(auto x, auto y) { x + y }

would be much more wholesome IMO. (The 'funcName(auto arg)' syntax is just a convenience suggestions; the important part is '{ x + y }').

That said, it does fix something that 'alias' should've been able to do from the beginning. I'm not sure what else but I think there other places where alias needs '= I!(stuff)' identity template to accept the 'stuff'.

On Saturday, 2 January 2016 at 15:04:15 UTC, Enamex wrote:
> On Friday, 1 January 2016 at 00:27:49 UTC, ZombineDev wrote:
>> By the way, a very similar language feature was approved and implemented for the upcomming DMD 2.070 release. It allows you to use a short syntax for function templates:
>>
>> alias add = (a, b) => a + b;
>> // Shorthand for:
>> // auto add(T1, T2)(T1 a, T2 b) { return a + b; }
>>
>> IFTI makes it look like a regular function call:
>> writeln(add(3, 4.5));
>>
>> It works for free functions, but I'm not sure if it would also work for member-functions (methods).
>>
>> https://issues.dlang.org/show_bug.cgi?id=12421
>
> IMHO, anything like that is just a tangential 'fix' to the fact that D's design rests on commands like 'return' to leave scope and return values.
>
> Something like
>
> auto add(auto x, auto y) { x + y }
>
> would be much more wholesome IMO. (The 'funcName(auto arg)' syntax is just a convenience suggestions; the important part is '{ x + y }').

Personally, I prefer the new alias syntax, (which sort of reminds me of Haskell), because it looks much cleaner than this mashup of Swift and C++14.

> That said, it does fix something that 'alias' should've been able to do from the beginning. I'm not sure what else but I think there other places where alias needs '= I!(stuff)' identity template to accept the 'stuff'.

The most obvious thing that comes to my mind are values (that enum accepts):
enum number = 3;
alias aliasedNumber = I!(3);

However wouldn't this blur the line between enum and alias too much?
Right now enum can refer only to values computed at compile-time, while alias can only refer to symbols*, which I think is a good separation.

* Alias to a function literal refers to the _symbol_ of the anonymous function template.

Maybe a good direction forward would be to allow alias to refer to expressions (i.e. similar to the AST macros idea), which you can introspect at CT (like with CT type reflection).

auto query = db.orders
    .where!@{price > 200}
    .select!(order => order.name);

@{...} looks like q{...} but would capture the AST of the expession between the braces (which must be valid D code).

auto where(alias predExpr, R)(R range)
    if (isInputRange!R &&
        isAstCapture!predExpr)
{
    // http://dlang.org/spec/expression.html#OrOrExpression
    static assert(__traits(isExpression, OrOrExpression, predExpr);

    // prepare where clause of SQL statement...
}