Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:37234 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 37189 invoked from network); 25 Apr 2008 19:18:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Apr 2008 19:18:50 -0000 Authentication-Results: pb1.pair.com header.from=sam@sambarrow.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=sam@sambarrow.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain sambarrow.com from 208.70.128.55 cause and error) X-PHP-List-Original-Sender: sam@sambarrow.com X-Host-Fingerprint: 208.70.128.55 smtp-gw29.mailanyone.net Received: from [208.70.128.55] ([208.70.128.55:43595] helo=smtp-gw29.mailanyone.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 38/5D-18287-99E22184 for ; Fri, 25 Apr 2008 15:18:49 -0400 Received: from mailanyone.net by smtp-gw29.mailanyone.net with esmtpsa (TLSv1:RC4-MD5:128) (MailAnyone extSMTP sam@sambarrow.com) id 1JpTRW-0001S3-Cc; Fri, 25 Apr 2008 14:18:46 -0500 To: Jeremy Privett Cc: Alain Williams , internals@lists.php.net In-Reply-To: <48122C14.7070705@omegavortex.net> References: <1209137410.6642.9.camel@sbarrow-desktop> <1209147362.20639.7.camel@sbarrow-desktop> <20080425182341.GB14490@mint.phcomp.co.uk> <1209149047.20639.18.camel@sbarrow-desktop> <48122C14.7070705@omegavortex.net> Content-Type: text/plain Date: Fri, 25 Apr 2008 15:15:44 -0400 Message-ID: <1209150944.20639.24.camel@sbarrow-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Return type hinting patch From: sam@sambarrow.com (Sam Barrow) On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett wrote: > Sam Barrow wrote: > > I figured it out, the syntax is now as follows: > > > > function a($b, $c) returns d { > > } > > > > I'll post an update soon. > > > > > > > > That's certainly a non-intuitive syntax. How about we take a page out of > the book of other C-style languages before trying to invent something > else? I agree with Stas, "return" and "returns" are not part of a > function definition. I don't think it's non-intuitive at all, and even so, it's the most intuitive we have. This ordering makes more sense to me at first glance (in the order I would think about things; scope, name, arguments, return).