While finishing up work on my parser and grammar specification I found this in container.d:

return equal!(function(Elem a, Elem b) => !_less(a,b) && !_less(b,a))
                     (thisRange, thatRange);

It seems to be some strange hybrid of the function literal syntax and the lambda syntax. It's not documented anywhere (surprise!) and I'm not sure if I should support it or file an accepts-invalid bug against DMD.

On 07/10/2013 01:24 AM, Brian Schott wrote:
> While finishing up work on my parser and grammar specification I found
> this in container.d:
>
> return equal!(function(Elem a, Elem b) => !_less(a,b) && !_less(b,a))
>                       (thisRange, thatRange);
>
> It seems to be some strange hybrid of the function literal syntax and
> the lambda syntax.

=>... is supposed to be just a shorthand for { return ...; }

> It's not documented anywhere (surprise!) and I'm not
> sure if I should support it or file an accepts-invalid bug against DMD.


I'd say support it and file a bug against the documentation.

There are severel comments in the part of the dmd front end that show the syntax that the parser is looking for. Here's a listing:

// function type (parameters) { statements... }
// delegate type (parameters) { statements... }
// function (parameters) { statements... }
// delegate (parameters) { statements... }
// function { statements... }
// delegate { statements... }
// (parameters) { statements... }
// { statements... }
// identifier => expression

Based on the fact that "function (parameters) => expression" isn't written out like the others, I'm going to file an accepts-valid bug for this.

On 07/10/2013 07:47 PM, Brian Schott wrote:
> There are severel comments in the part of the dmd front end that show
> the syntax that the parser is looking for. Here's a listing:
>
> // function type (parameters) { statements... }
> // delegate type (parameters) { statements... }
> // function (parameters) { statements... }
> // delegate (parameters) { statements... }
> // function { statements... }
> // delegate { statements... }
> // (parameters) { statements... }
> // { statements... }
> // identifier => expression
>
> Based on the fact that "function (parameters) => expression" isn't
> written out like the others, I'm going to file an accepts-valid bug for
> this.

Accepts-valid is not a bug.

On Wednesday, 10 July 2013 at 18:17:07 UTC, Timon Gehr wrote:
> Accepts-valid is not a bug.

I think you know what I meant. :-)

On 07/10/2013 08:47 PM, Brian Schott wrote:
> On Wednesday, 10 July 2013 at 18:17:07 UTC, Timon Gehr wrote:
>> Accepts-valid is not a bug.
>
> I think you know what I meant. :-)

Well, I am going to guess you meant accepts-invalid, though I'd prefer if you didn't. :o)

On 07/10/2013 07:47 PM, Brian Schott wrote:
> There are severel comments in the part of the dmd front end that show
> the syntax that the parser is looking for. Here's a listing:
>
> // function type (parameters) { statements... }
> // delegate type (parameters) { statements... }
> // function (parameters) { statements... }
> // delegate (parameters) { statements... }
> // function { statements... }
> // delegate { statements... }
> // (parameters) { statements... }
> // { statements... }
> // identifier => expression
>
> Based on the fact that "function (parameters) => expression" isn't
> written out like the others,

You mean, like some others.

> I'm going to file an [...] bug for this.

// (parameters) => expression ?

In any case, please consider that it actually makes no sense to restrict the expressiveness of the type signature based on how the function body is specified. (Why on earth should one have to use the { return expression; } syntax just in order to be able to assert that no context pointer is required?)

The documentation is in error here.

On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote:
> // (parameters) => expression ?
>
> In any case, please consider that it actually makes no sense to restrict the expressiveness of the type signature based on how the function body is specified. (Why on earth should one have to use the { return expression; } syntax just in order to be able to assert that no context pointer is required?)
>
> The documentation is in error here.

"(parameters) => expression" is mentioned in the source and I agree it's valid. I must have forgotton to copy-paste it.

I don't agree that "function(parameters) => expression" is valid though. Can any of the DMD devs clear up if this is intended?

On 07/10/2013 02:32 PM, Brian Schott wrote:
> On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote:
>> The documentation is in error here.
>
> "(parameters) => expression" is mentioned in the source and I agree it's
> valid. I must have forgotton to copy-paste it.
>
> I don't agree that "function(parameters) => expression" is valid though.
> Can any of the DMD devs clear up if this is intended?

According to spec "function(parameters) => expression" is not valid.

  http://dlang.org/expression.html

Lambda:
    Identifier => AssignExpression
    ParameterAttributes => AssignExpression

Neither of those allow 'function' or 'delegate' keyword. However, I agree with Timon Gehr that the spec should be changed to match the current behavior.

Ali

On 07/10/2013 11:32 PM, Brian Schott wrote:
> On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote:
>> // (parameters) => expression ?
>>
>> In any case, please consider that it actually makes no sense to
>> restrict the expressiveness of the type signature based on how the
>> function body is specified. (Why on earth should one have to use the {
>> return expression; } syntax just in order to be able to assert that no
>> context pointer is required?)
>>
>> The documentation is in error here.
>
> "(parameters) => expression" is mentioned in the source and I agree it's
> valid. I must have forgotton to copy-paste it.
>
> I don't agree that "function(parameters) => expression" is valid though.

Yes, you said that. What I do not understand is why. I think common sense would mandate that it should be valid syntax.

> Can any of the DMD devs clear up if this is intended?

This is the relevant pull:

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