Re: [RFC] Return Type Declarations

Hi, Why using an additional ":" symbol for the return type? what about considering this: function foo() string { } and for closure: $bar = 1; $foo = function() use ($bar) string { }; I think removing ":" symbol is cleaner. On Tue, Apr 29, 2014 at 11:10 PM, Larry Garfield <larry@garfieldtech.com>wrote: > On 4/28/14, 8:30 PM, Levi Morrison wrote: > > I will attempt to contact the HHVM team (perhaps SaraG) to see if there >>>> was >>>> a technical reason for it. >>>> >>>> >>> I would agree, and look forward to seeing their reasoning. >>> >> >> >> HHVM puts the return type before the use case because: >> >> - A user is already familiar with function(): Foo >> - A use statement is not really part of the function signature (during >> inheritance and such) >> >> Additionally, it is common to write closures using their shorthand >> notation: ==> (see >> http://docs.hhvm.com/manual/en/hack.lambda.php) >> >> I would counter: >> - Use statements are special parameters (similar to constructor >> arguments) and that putting it after the use statement makes more sense >> - Putting it after use statements is less ugly. >> - Putting it before the use statement is a bit confusing; consider this >> Hack declaration: >> $i = 0; >> $inc = function(): Iterator<int> use(&$i) {//... >> It looks like the Iterator<int> is somehow using $i. >> >> What does this list think? >> > > Honestly I don't much care for the compact lambda syntax in Hack as I like > that PHP is explicit on variable capture. (Javascript isn't, and it's a > common source of errors; see the "never do this" comment on the link above.) > > <bikeshed> > > I subjectively like the return at the very end, too. The return is the > "last" thing that matters, so it comes at the end. Too, it clusters all of > the inputs together (parameters and closures) followed by the output > (return). > > </bikeshed> > > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Best Regards, Yo-An Lin