Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110818
MIME-Version: 1.0
References: <CAFPFaMK2ku+Jicv2znPnOb7RUQRc8iyVxRNOzjxRRmZh04RB2A@mail.gmail.com>
 <A3CDC880-BF7D-47EB-A3D3-63037C543E15@gmail.com> <CAFPFaM+yLUFj5+HFn7RQw47nYFGFbqY1XQfqYsyb-1Pt=7JUjg@mail.gmail.com>
 <CAFPFaMJZAWLbasiJetSGJAj+LnWUGSyB5J79tj=ydz=jBCXHrg@mail.gmail.com>
 <CAFPFaM+T_n6i2G6DUG=PNmBRykkbhx-Fsi+cUhYHRvTkJ4ndrw@mail.gmail.com> <CALKiJKrDF+s3PB0DzZkMtGs6L=2QHz44-gZ5wiNumVmyz+-8gQ@mail.gmail.com>
In-Reply-To: <CALKiJKrDF+s3PB0DzZkMtGs6L=2QHz44-gZ5wiNumVmyz+-8gQ@mail.gmail.com>
Date: Thu, 2 Jul 2020 14:05:28 +0200
Message-ID: <CAFPFaMJ1gYWUGuAtoqE7D4smuHodAiY8xmqzv-bqwc713NRh=g@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001f046005a9743ac5"
Subject: Re: [PHP-DEV][RFC] Saner numeric strings
From: george.banyard@gmail.com ("G. P. B.")

--0000000000001f046005a9743ac5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 1 Jul 2020 at 18:44, Rowan Tommins <rowan.collins@gmail.com> wrote:

> Hi George,
>
> On Wed, 1 Jul 2020 at 15:26, G. P. B. <george.banyard@gmail.com> wrote:
>
>>
>>    2. Emit the E_WARNING "Illegal string offset" and evaluate to 0 for
>>    offsets like '2str', and emit the E_WARNING "String offset cast
>>    occurred" for float numeric strings like '2.5'
>
>
>
> I'm not clear how this option fits with the rest of the RFC; there's no
> explicit mention of evaluating values to 0 which would previously have be=
en
> evaluated differently. That would fall into the most significant category
> of BC breaks: working code in version X still works in version Y, but
> produces different results.
>
> At the moment, the "Backward Incompatible Changes" section just says:
>
> > code with liberal use of leading-numerical strings will need to be
> updated
>
> It would be good to expand that with examples of what such code would loo=
k
> like, how it would behave before and after, and what updates the user wou=
ld
> need to make.
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>

I've had another thought about while I was implementing this change.
I've updated the RFC to reflect what I think is a more reasonable approach:

> For string offsets accessed using numeric strings the following changes
> will be made:
>
>    - numeric strings which correspond to well formed floats will emit the
>    more usual =E2=80=9CString offset cast occurred=E2=80=9D warning inste=
ad of the =E2=80=9CIllegal
>    string offset=E2=80=9D one.
>    - leading numeric strings will emit the =E2=80=9CIllegal string offset=
=E2=80=9D
>    instead of the =E2=80=9CA non well formed numeric value encountered=E2=
=80=9D notice, and
>    continue to evaluate to their respective values.
>    - Non-numeric strings which emmited the =E2=80=9CIllegal string offset=
=E2=80=9D
>    warning will throw an =E2=80=9CIllegal offset type=E2=80=9D TypeError
>
> The only aspect I'm not totally convinced is making well formed float
strings more "legal" than they were in PHP 7.x.

I will also flesh out the RFC with more examples and which code is affected
and how it would need to be updated to produce the previous behaviour.

Best regards

George P. Banyard

--0000000000001f046005a9743ac5--