Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:77182 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 12744 invoked from network); 14 Sep 2014 15:09:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Sep 2014 15:09:40 -0000 Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.208 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 192.64.116.208 imap2-3.ox.privateemail.com Received: from [192.64.116.208] ([192.64.116.208:39554] helo=imap2-3.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 63/C8-53483-3BFA5145 for ; Sun, 14 Sep 2014 11:09:40 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id CE4478C0081; Sun, 14 Sep 2014 11:09:36 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at imap2.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap2.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CksHRYQRNKLL; Sun, 14 Sep 2014 11:09:36 -0400 (EDT) Received: from oa-res-27-90.wireless.abdn.ac.uk (oa-res-27-90.wireless.abdn.ac.uk [137.50.27.90]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id 5A7B78C0080; Sun, 14 Sep 2014 11:09:33 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) In-Reply-To: Date: Sun, 14 Sep 2014 16:09:31 +0100 Cc: Zeev Suraski , Stas Malyshev , "internals@lists.php.net" Content-Transfer-Encoding: quoted-printable Message-ID: <8556C1E7-EDF3-47E2-9DA0-C9AB63DE56E6@ajf.me> References: <6893A97A-EC4C-4124-B804-96E2A26B953F@ajf.me> <20140914000718.GB14312@phcomp.co.uk> <3177B936-50C1-4E5D-8687-FD235C72B411@ajf.me> <54153692.7050500@sugarcrm.com> <9CE963B0-E624-4267-BC2A-0F8D1F985DAE@ajf.me> <6f2236e18c61d30b247e1c6bb2de10f1@mail.gmail.com> To: Andrey Andreev X-Mailer: Apple Mail (2.1878.6) Subject: Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast From: ajf@ajf.me (Andrea Faulds) On 14 Sep 2014, at 15:56, Andrey Andreev wrote: > It seems a bit political ... A lot of people want either strict type > hints or type casting hints, but because the people on this list can't > get to agree on any of the two, this RFC tries to make a compromise > that, IMO, satisfies nobody. It's done not for the benefit of > everybody, but just so we can say that PHP has "scalar type hints". > I've said this in the RFC discussion thread: In order to satisfy both > sides, instead of arguing which is the one and true way, just > implement both. I=92m not sure it satisfies nobody. I realise a lot of people would = prefer strict types, but plenty are still in favour of this as a = compromise: http://strawpoll.me/2463199/r - Might not be representative, but I held = a poll on Twitter and StackOverflow. There are the results. 67 would = vote in favour of strict hints (=E0 la Hack), and 36 would vote in = favour of this RFC, with only 5 willing to vote against it, versus 10 = voting against strict hints. Note that the options aren=92t mutually = exclusive.=20 > That is also why I suggested altering the proposed syntax here from: >=20 > function foo(int $bar) >=20 > to: >=20 > function foo((int) $bar) But it=92s not a cast. Such a syntax would be misleading. You would = reasonably expect the following two functions to be equivalent: function foo($bar) { $bar =3D (int)$bar; } function foo((int) $bar) { } Yet they are not equivalent at all.=20 > Whether it applies more strict rules or not, this RFC is clearly about > type _casting_ hints, while the used syntax has so far only been used > for strict type hints. Well, we haven=92t had any scalar hints so far. It=92s also worth noting = that the documentation for PHP uses this style even though internal = functions are not strict. Furthermore, scalar types in PHP are = fundamentally different from non-scalar types. We do not have weak = typing for non-scalars: there are no implicit casts between non-scalar = types. However, we implicitly convert and juggle the scalar types all = the time. > I know some would argue that this is a side > effect because you can't cast to a specific class type, but that's not > the point - the result is a strict type hint and that's what people > are used to. This is both inconsistent AND prevents PHP from having > strict scalar type hints in the future (because of the used syntax). Strict hints would still be possible with different syntax. However, I=92m= not sure they=92re a good idea. Strict hints would be abandoning PHP=92s = weakly-typed nature, and would segregate userland functions into two = kinds: strict and non-strict. I also don=92t expect that would pass = internals anyway. I don=92t think permitting multiple options is really the way forward, = that sounds like the worst of both worlds.=20 -- Andrea Faulds http://ajf.me/