Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113368
To: internals@lists.php.net
References: <CAF+90c-93pAMM3XYrj=G_Z+uaTRTgzdEOULYwKUj7Hp64FBp6w@mail.gmail.com>
 <c79fe1ef-433a-72d7-9b89-ae279b39a1f5@gmail.com>
 <E0DF66AE-A0DC-4715-8771-5D9EC81A6BFB@cschneid.com>
 <CAGBsUrdEsW2ZhRpmus=6C5gnWvh=CJEA59Edtr7sZ+s2zTVPGw@mail.gmail.com>
 <424A5E98-2110-4AFE-9C53-8636A6140313@benramsey.com>
 <F1D9E7C0-96D3-480C-AE9B-E5559FD8D861@cschneid.com>
 <CAF+90c8u_x3ZOADesgwauxuUjy+a2D+r+Q60OOgqZD3vC9QYeQ@mail.gmail.com>
Message-ID: <e499207f-8f3e-8513-fede-a2e21f98e2fe@gmail.com>
Date: Thu, 4 Mar 2021 12:03:02 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c8u_x3ZOADesgwauxuUjy+a2D+r+Q60OOgqZD3vC9QYeQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Don't compare zero exponentials in strings as equal
From: rowan.collins@gmail.com (Rowan Tommins)

On 04/03/2021 10:54, Nikita Popov wrote:
> The main one that comes to mind is something like '0' == '0.0'. However,
> the real problem is something else: Comparison behavior doesn't affect just
> == and !=, but also < and >. And I can see how people would want '2' < '10'
> to be true (numeric comparison) rather than false (lexicographical
> comparison).


That's a very good point, and I think the existence of the <=> makes 
this even more complicated.


Considering your two options:

> 1. Decouple equality comparison from relational comparison. Don't handle
> numeric strings for == and !=, but do handle them for <, >, etc.


What would then be the result of '0' <=> '0.0'? Would the operator need 
to special case the fact that they are numerically equal but 
lexicographically unequal?


> 2. Don't allow relational comparison on strings. If you want to compare
> them lexicographically, use strcmp(), otherwise cast to number first.


This is easy to *implement* for the <=> operator, but makes it much less 
useful. Part of the appeal of the operator is that you can write code 
like $sortCallback = fn($a,$b) => $a[$sortField] <=> $b[$sortField]; 
without needing different cases for different data types.

Granted, that's not going to use an appropriate sorting collation for 
many languages, but nor is strcmp().


I think further narrowing the definition of "numeric string" is a more 
useful course. If we were designing from scratch, the straight-forward 
definition would be:

- all digits: /^\d+$/
- or, all digits with leading hyphen-minus: /^-\d+$/
- or, at least one digit, a dot, and at least one more digit: /^\d+\.\d+$/
- or, as above, but with leading hyphen-minus: /^-\d+\.\d+$/

I think anything beyond that list needs to be carefully justified.

- Leading and trailing spaces are probably OK. Other whitespace 
(newlines, tabs, etc) probably not.
- Alternative notations like hexadecimal and exponentials are easy to 
have false positive matches, and how common are they in practice?
- Leading and trailing dots (".5", "1.") might be used sometimes, but 
I'd probably lean against

So, ignoring BC concerns, I would be happy with "numeric string" defined 
as "maybe space, maybe hyphen, some digits, maybe a dot and more digits, 
maybe space", which I think in regex form looks like /^ *-?\d+(\.\d+)? *$/


Regards,

-- 
Rowan Tommins
[IMSoP]