Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104964
MIME-Version: 1.0
References: <php.internals-104590@news.php.net> <cee93791-8516-4653-9d8e-af70bd7e1a0c@BL2NAM02FT006.eop-nam02.prod.protection.outlook.com>
 <DM5PR06MB2857BD900DFC1510DD3EA314DE5F0@DM5PR06MB2857.namprd06.prod.outlook.com>
 <CAG9XoMSktgyZ_634JyOEU_ov-kEjhhEWaxEEo31th5x+0f8M1A@mail.gmail.com>
 <b4752b1a-c89d-0f4b-dd20-48cfe3747677@gmail.com> <CAG9XoMRnK+ceLHa5kHQkZRF9w3pEhmpoVaW2dEoaHRHdOdDHCQ@mail.gmail.com>
 <6C077569-A049-422B-A4CD-6EE5F8DEC388@gmail.com>
In-Reply-To: <6C077569-A049-422B-A4CD-6EE5F8DEC388@gmail.com>
Date: Wed, 27 Mar 2019 14:29:47 +0100
Message-ID: <CAG9XoMRn9v4MfH6w-xdeGRhYpZV=L2gx0YxJR6UmQCLqxA91uA@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000033fc4f0585136fd8"
Subject: Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings
From: benjamin.morel@gmail.com (Benjamin Morel)

--00000000000033fc4f0585136fd8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> It is a well-known feature that you can work with such data without
previously converting it explicitly to some number type.

I'm not requesting to change this: if you're doing string("3.5") + int(7),
you should still get float(10.5). What I'm suggesting we change, is
comparison of numbers and decimal strings.

Thinking about this a bit more, what about following JavaScript semantics?
I find them really good in this respect:

- when comparing two strings, always use strcmp():

var_dump("42" =3D=3D "42.0"); // false
var_dump("3" < "23"); // false

- when comparing a number with a string, cast the string to a number, then
compare:

var_dump(3 < "23"); // true
var_dump("3" < 23); // true
var_dump(42 =3D=3D "42"); // true
var_dump(42.0 =3D=3D "42"); // true
var_dump(42.5 =3D=3D "42.5"); // true
var_dump(42 =3D=3D "42.0"); // true

- if the string does not represent a valid number, always return false:

var_dump(42 =3D=3D "42x"); // false
var_dump(42 =3D=3D "x42"); // false
var_dump(1 >=3D "abc"); // false
var_dump(1 < "abc"); // false

Note: JavaScript actually allows leading & trailing whitespace around the
number:

var_dump(42 =3D=3D " 42 "); // true

On this last point, I'm not sure whether we should allow both leading &
trailing whitespace, or disallow both of them.
Other than that, I love the way they handle implicit conversions here. It's
so much more understandable, easy to remember, and less prone to errors IMO=
.

Ben

On Wed, 27 Mar 2019 at 11:28, Claude Pache <claude.pache@gmail.com> wrote:

>
>
> > Le 27 mars 2019 =C3=A0 00:09, Benjamin Morel <benjamin.morel@gmail.com>=
 a
> =C3=A9crit :
> >
> >  - I would also strongly suggest that 2 strings are always compared
> > byte-by-byte; IMO it does (*somehow*) make sense that 42 =3D=3D "42.0",=
 but
> it
> > DOES NOT make sense that "42" =3D=3D "42.0". (...)
>
> There are many ways to obtain numeric data in the form of a string from
> external sources (HTML form, database, CSV, ...) and even internal source=
s
> (bcmath, ...)=E2=80=94and note that, even when such numerical data may ha=
ve a
> decimal part, it does *not* mean that they are imprecise. It is a
> well-known feature that you can work with such data without previously
> converting it explicitly to some number type. That works pretty well in P=
HP
> (well, except that you get intermittent obscure bugs when some third-part=
y
> code in the same thread plays with setlocale(), but that's another
> story...) If we cease to compare numeric strings numerically, I expect th=
at
> much code will begin to break more or less subtly, and will need to be
> thoroughly reviewed in order to be corrected. We must not change that.
>
> The core issue is that =E2=80=9C=3D=3D=E2=80=9D is fundamentally ambiguou=
s: should it compare
> as number, as string, as reference, ...? If we were to redesign PHP from
> scratch, we may decide other semantics than the current one (e.g., use
> distinct operators for comparing numerically and textually, as does Perl)=
.
> But where we are now, the best thing to do is to follow the common wisdom=
:
> If you want to compare strings as strings, just use =E2=80=9C=3D=3D=3D=E2=
=80=9D. Or strcmp.
>
> =E2=80=94Claude
>
>

--00000000000033fc4f0585136fd8--