Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75691 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 12936 invoked from network); 18 Jul 2014 15:46:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Jul 2014 15:46:28 -0000 Authentication-Results: pb1.pair.com smtp.mail=theodorejb@outlook.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=theodorejb@outlook.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain outlook.com designates 65.55.111.156 as permitted sender) X-PHP-List-Original-Sender: theodorejb@outlook.com X-Host-Fingerprint: 65.55.111.156 blu004-omc4s17.hotmail.com Received: from [65.55.111.156] ([65.55.111.156:51971] helo=BLU004-OMC4S17.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9A/E0-07285-25149C35 for ; Fri, 18 Jul 2014 11:46:28 -0400 Received: from BLU179-W72 ([65.55.111.137]) by BLU004-OMC4S17.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Fri, 18 Jul 2014 08:46:24 -0700 X-TMN: [yGNJFp7TsoyIbAMdPVV7kOHY0kWquLox] X-Originating-Email: [theodorejb@outlook.com] Message-ID: To: Andrea Faulds CC: "internals@lists.php.net" Date: Fri, 18 Jul 2014 10:46:23 -0500 Importance: Normal In-Reply-To: <20A80B2E-42BB-486F-8F83-A6FDBEBA4056@ajf.me> References: ,<20A80B2E-42BB-486F-8F83-A6FDBEBA4056@ajf.me> Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jul 2014 15:46:24.0208 (UTC) FILETIME=[6DC3C500:01CFA29F] Subject: RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening) From: theodorejb@outlook.com (Theodore Brown) >> Another concern I have is in regard to the future. I'm looking=0A= >> forward to the possibility of specifying nullable types in a=0A= >> future version of PHP (see Levi Morrison's "Declaring Nullable=0A= >> Types" RFC: http://wiki.php.net/rfc/nullable_typehints). If the=0A= >> nullable types RFC is accepted=2C it would be highly disconcerting=0A= >> if scalar type annotations allowed null values regardless of=0A= >> whether a nullable marker is specified.=0A= >=0A= > The current proposed behaviour could be changed. At the moment=2C if=0A= > a scalar type hint is nullable=2C then it won=92t cast NULL if it=92s=0A= > passed that value=2C but if it=92s not nullable=2C then it will cast it.= =0A= >=0A= > Considering how this tends to only allow lossless casts=2C though=2C it= =0A= > might be worth reconsidering this and just disallowing NULL=0A= > altogether. It=92s worth pointing out that NULL is usually an error=0A= > value=2C and you might get it from using an uninitialised variable or=0A= > calling an internal function with bad parameters.=0A= =0A= The same thing applies to boolean values. FALSE is frequently returned=0A= from=A0internal functions when an error occurs=2C and allowing it to be=0A= passed to a function expecting a different scalar type could mask errors.= =0A= =0A= After reading Simon's response I do feel it would be a reasonable=0A= compromise to allow strings to be cast to int/float (and vice versa) as=0A= long as no data loss occurs (following the current rules in the RFC).=0A= If the RFC is updated to disallow NULL altogether and also disallow=0A= boolean values for other scalar types I would be 100% supportive.=0A= =0A= --=0A= =0A= Theodore Brown=0A= =0A= A PHP developer interested in the future of the language=0A= =0A= =