Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104967
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> <CAG9XoMRn9v4MfH6w-xdeGRhYpZV=L2gx0YxJR6UmQCLqxA91uA@mail.gmail.com>
 <481CB4EE-599D-4CFE-9F5E-8B04EC2BAB35@gmail.com>
In-Reply-To: <481CB4EE-599D-4CFE-9F5E-8B04EC2BAB35@gmail.com>
Date: Wed, 27 Mar 2019 16:14:09 +0100
Message-ID: <CAG9XoMTTHOioP0g10pPaki6++RtZXvN0A=tMU0xaKJsWv77RGQ@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="0000000000007278e8058514e44d"
Subject: Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings
From: benjamin.morel@gmail.com (Benjamin Morel)

--0000000000007278e8058514e44d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>  Isn't this the purpose of Nikic's Saner PHP String comparison RFC?

It is, sorry I mixed the discussions here. As I said below, I think that
these RFCs would deserved to be merged.

> Because boths nikic's and Andrea's RFC go hand in hand.
> And probably if both these RFC get accepted a new "stricter numerical
string comparison" RFC could see the light
banning leading and trailling whitespace

I'd rather tackle the whole thing right now, as PHP 8 is a good opportunity
for whatever BC break this will cause. Another such opportunity will not
happen again before many years.

> Arithmetic in JavaScript cannot be used reliably (in general) without
converting your data to the proper type, because 1 + 1 gives you 11 if one
of the 1s is encoded as string. PHP does a better job in that respect

Sure, PHP has the huge advantage here to have a dedicated string
concatenation operator, removing any ambiguity around the + operator. This
does not mean that we cannot borrow their semantics for string/number
*comparison*!

Ben


On Wed, 27 Mar 2019 at 15:26, Claude Pache <claude.pache@gmail.com> wrote:

>
> > Le 27 mars 2019 =C3=A0 14:29, Benjamin Morel <benjamin.morel@gmail.com>=
 a
> =C3=A9crit :
> >
> > Thinking about this a bit more, what about following JavaScript
> semantics? I find them really good in this respect:
> >
>
> Arithmetic in JavaScript cannot be used reliably (in general) without
> converting your data to the proper type, because 1 + 1 gives you 11 if on=
e
> of the 1s is encoded as string. PHP does a better job in that respect. As=
 a
> result, there is good chance that people (it is at least the case for me)
> are more confident to rely (often implicitly) on automatic type conversio=
n
> between strings and numbers when doing basic arithmetic in PHP than in JS=
,
> including for comparison of numeric values.
>
> About leading/trailing whitespaces: usually, numbers encoded as strings d=
o
> not contain them; so that it may be OK to consider strings containing the=
m
> as non-numeric if we want.
>
> =E2=80=94Claude
>
>

--0000000000007278e8058514e44d--