On Thursday, 11 July 2013 at 04:59:14 UTC, Kenji Hara wrote:
I filed the website bug in bugzilla, and posted pull request.
http://d.puremagic.com/issues/show_bug.cgi?id=10605
https://github.com/D-Programming-Language/dlang.org/pull/351
Kenji Hara
http://msalvarez1.edublogs.org/files/2010/01/
I filed the website bug in bugzilla, and posted pull request.
http://d.puremagic.com/issues/show_bug.cgi?id=10605
https://github.com/D-Programming-Language/dlang.org/pull/351
Kenji Hara
2013/7/11 Kenji Hara
> This is accepts-valid behavior.
>
> function(parameters) => expr
>
> means the combi
This is accepts-valid behavior.
function(parameters) => expr
means the combination of:
1. specifying "context pointer is not necessary"
2. lambda syntax "(parameters) => expr"
I think website documentation has a bug.
Kenji Hara
2013/7/10 Brian Schott
> While finishing up work on my parser
On Wednesday, 10 July 2013 at 21:33:00 UTC, 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 func
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
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 "f
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
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)
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 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 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)
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) {
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 f
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 synt
14 matches
Mail list logo
