Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113373
MIME-Version: 1.0
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> <e499207f-8f3e-8513-fede-a2e21f98e2fe@gmail.com>
In-Reply-To: <e499207f-8f3e-8513-fede-a2e21f98e2fe@gmail.com>
Date: Thu, 4 Mar 2021 14:17:26 +0100
Message-ID: <CAF+90c8QryKkjosUzgUB68AbYr6DOJDhTZG8DjTuYC0Hu9x+HQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ef1dca05bcb5ca89"
Subject: Re: [PHP-DEV] Don't compare zero exponentials in strings as equal
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000ef1dca05bcb5ca89
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 4, 2021 at 1:03 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> 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?
>

Both '0' <=> '0.0' and '0.0' <=> '0' would return 1 in that case, which is
PHP's indication that values are non-comparable. It's definitely not a good
option.


> > 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+)? *$/
>

A disadvantage of narrowing the definition in such a fashion is that it
introduces a discrepancy with (float) casts. I believe these currently
recognize the same values, with the exception that (float) discards
trailing garbage.

Another disadvantage is that exponential notation is commonly returned for
large numbers by various data source -- e.g. if you stored a large float in
a database, I'd expect you'd get it back in exponential notation (if you
get it back as a string). This means that your code could suddenly break
because the range of a value passes some heuristic threshold for how it
gets printed.

Regards,
Nikita

--000000000000ef1dca05bcb5ca89--