Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91943 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 76418 invoked from network); 25 Mar 2016 12:15:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Mar 2016 12:15:26 -0000 X-Host-Fingerprint: 178.62.40.5 ajf.me Received: from [178.62.40.5] ([178.62.40.5:28948] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AB/00-10214-EDB25F65 for ; Fri, 25 Mar 2016 07:15:26 -0500 Message-ID: To: internals@lists.php.net References: <51.DA.15440.52E44F65@pb1.pair.com> <56F45B65.5090401@telia.com> Date: Fri, 25 Mar 2016 12:15:23 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: <56F45B65.5090401@telia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 178.62.40.5 Subject: Re: [PHP-DEV] [VOTE] Warn about invalid strings in arithmetic From: ajf@ajf.me (Andrea Faulds) Hi Björn, Björn Larsson wrote: > Den 2016-03-24 kl. 21:29, skrev Andrea Faulds: > Came to think on a conversation with Sara G last year about introducing > the following operators, namely >==, <== & <==> working exactly like the > existing ones but without type juggling. > > Maybe that would alleviate some of the issue here, giving new tools at > hand when writing new or updating existing code? This is an interesting idea. === and !== avoid type juggling by returning FALSE if the types of their operands don't match, so what would these hypothetical strict versions of < and > do in that situation? One approach would be to order by type, so any integer < any float < any string, for example. I think I'd like that, it'd be more predictable than PHP's current comparison operators, where "1" < "a" < "b" < 1 < "2" < 2. I'm not sure about those symbols, though. Given their appearance I'd think >== and <== would be strict versions of >= and <=, even though I think you're proposing them to be strict versions of > and <. But surely something could be figured out. Thanks! -- Andrea Faulds https://ajf.me/