Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:89945 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 19346 invoked from network); 31 Dec 2015 19:26:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Dec 2015 19:26:19 -0000 X-Host-Fingerprint: 2.218.134.247 unknown Received: from [2.218.134.247] ([2.218.134.247:11044] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5B/0F-51216-A5185865 for ; Thu, 31 Dec 2015 14:26:18 -0500 Message-ID: <5B.0F.51216.A5185865@pb1.pair.com> To: internals@lists.php.net References: Date: Thu, 31 Dec 2015 19:26:14 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 2.218.134.247 Subject: Re: [PHP-DEV] [RFC] Number Format Separator From: ajf@ajf.me (Andrea Faulds) Hi Davey, Davey Shafik wrote: > You mention no support for numeric strings, but how will settype($string, > int|float), intval(), floatval(), is_numeric() and ctype_digit() work with > this change? > > I do think if you don't change the semantics for strings to number > conversion (which I agree you can't due to BC breaks) there should be an > explicit way to support "1_000_000" => (int) 1_000_000. This should be part > of the RFC. > > I presume that if you were to go from numeric to string the underscores > would be stripped? What about a way not to do that? What will var_dump() > etc. show? Numeric string conversions, in all their forms (I'm including intval() and such here) don't follow the same rules as PHP's integer and float literals. This isn't at all new. Here's some examples of existing differences between literals and numeric strings: - "0x123" != 0x123 Hexadecimal isn't supported in numeric strings. - "-0.0" != -0.0 PHP's numeric literals do not have signs. Rather, a preceding - or + symbol is parsed as a unary minus/plus. Before PHP 7.0.2, negating a floating-point zero did not produce negative zero, which was incorrect behaviour. PHP's numeric string parser, however, *does* support signs, and interprets "-0.0" is meaning negative zero. - "0123" != 0123 Octal isn't supported in numeric strings. - "0b101" != 0b101 Binary isn't supported in numeric strings. - 0 + "-9223372036854775808" !== -9223372036854775808 As previously mentioned, PHP's numeric literals lack signs. Here, this means that -9223372036854775808 is parsed as -(9223372036854775808). 9223372036854775808 is too large to be an integer, so it is a float. However, PHP's numeric string parser does support signs, and "-9223372036854775808" fits within the range of an integer. As you can see, not supporting _ as a number separator here would not be terribly surprising. It would also be a backwards-compatibility break: currently, (int)"123_4" is parsed as 123, but it would be 1234 if we changed the coercion rules. Thanks. -- Andrea Faulds http://ajf.me/