Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105191 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 1235 invoked from network); 10 Apr 2019 11:35:39 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 10 Apr 2019 11:35:39 -0000 To: internals@lists.php.net References: <40683e93-f8e9-5a8c-9646-31c73c99396f@fischer.name> <5ca53eb4.1c69fb81.e223b.922eSMTPIN_ADDED_MISSING@mx.google.com> Date: Wed, 10 Apr 2019 09:32:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Posted-By: 94.0.205.114 Subject: Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings From: markyr@gmail.com (Mark Randall) Message-ID: On 09/04/2019 14:27, Robert Hickman wrote: >> Why? Wouldn't it be nice to align the behaviour of implicit and explicit >> casting, so that (int) "abc" throws a TypeError? I'm somewhat split on this one. On the one hand, if I make an explicit cast, my intention is clear, make the best attempt to convert this string into a number. Trimming whitespace would be a natural consequence of that. On the other hand, I'm a stickler for consistency. On the balance of things, I would most certainly like to see leading and trailing whitespace render a string ineligible to be implicitly converted, but I'd be satisfied with (int)" 123 " converting without error. On the topic of errorsfor explicit casts I'd be more inclined to also introduce (?int) and in the event the value cannot be converted, return null. As long as the precidence worked out, it would allow: $output = (?int)$input ?? $default; -- Mark Randall