Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73846
Return-Path: <larry@garfieldtech.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 656 invoked from network); 29 Apr 2014 15:10:26 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 29 Apr 2014 15:10:26 -0000
Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown
Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error)
X-PHP-List-Original-Sender: larry@garfieldtech.com
X-Host-Fingerprint: 66.111.4.25 out1-smtp.messagingengine.com  
Received: from [66.111.4.25] ([66.111.4.25:43506] helo=out1-smtp.messagingengine.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 08/68-57832-1E0CF535 for <internals@lists.php.net>; Tue, 29 Apr 2014 11:10:25 -0400
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5C352218CC
	for <internals@lists.php.net>; Tue, 29 Apr 2014 11:10:23 -0400 (EDT)
Received: from frontend1 ([10.202.2.160])
  by compute1.internal (MEProxy); Tue, 29 Apr 2014 11:10:23 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; s=smtpout; bh=0ei8oqgmRN6yfQDwzJ47Ga
	p8Ygw=; b=UhRZl0+m2w/ad9IAEXfHyJLn6gK7NBFCqE1CRRuhqLBcUm2GoReTGx
	kfSc743qnWDwYm9/vVrFrXlNdlmq6rt5etl3jy64HReEjjoLHjvuAs0JWkGWFJ1w
	CxinPMIvTEplcgu4EbNyW/NoCFsD6pFGeSSz74FF0OERDE+Uwf+oU=
X-Sasl-enc: rrTGeh4w36PflCUqdrClJBz7NADmtJR7aZSKTbVJhChX 1398784223
Received: from Palantirs-MacBook-Pro-2.local (unknown [63.250.249.138])
	by mail.messagingengine.com (Postfix) with ESMTPA id 21832C00003
	for <internals@lists.php.net>; Tue, 29 Apr 2014 11:10:23 -0400 (EDT)
Message-ID: <535FC0DE.5050709@garfieldtech.com>
Date: Tue, 29 Apr 2014 10:10:22 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAFMT4NoUZ7==rmLtuohHrddNnurOe-quPL9q_=WbdNV+jo1kYA@mail.gmail.com>	<535E9AED.2080904@garfieldtech.com>	<CAFMT4NqP5fB4PMWn6_uWtpG=MtukMheXjd7epX4Jz7sQdydGOQ@mail.gmail.com>	<535ECB9E.5050701@garfieldtech.com> <CAFMT4NqGRoU_bAaoNJfuRotXwEHAHpca2KrF5hScCMX8T5_Ohw@mail.gmail.com>
In-Reply-To: <CAFMT4NqGRoU_bAaoNJfuRotXwEHAHpca2KrF5hScCMX8T5_Ohw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Return Type Declarations
From: larry@garfieldtech.com (Larry Garfield)

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