Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124542
Feedback-ID: id5114917:Fastmail
Date: Sun, 21 Jul 2024 21:55:12 +0100
To: internals@lists.php.net
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D_Request_for_opinions=3A_bug_vs_f?=
 =?US-ASCII?Q?eature_-_change_intokenization_of_yield_from?=
User-Agent: K-9 Mail for Android
In-Reply-To: <669D5467.4090103@adviesenzo.nl>
References: <66984FD0.5090805@adviesenzo.nl> <AM8P250MB0170FFCA0014FB9EC272DB4FE2AC2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM> <c9736385-94b7-4064-911f-e5fc1df7e2bd@gmx.de> <AM8P250MB0170B4C59B4313A565CD029AE2AC2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM> <6699F817.8070806@adviesenzo.nl> <9571bb82-9873-4319-9bd1-0361748335be@bastelstu.be> <669BDB00.70507@adviesenzo.nl> <fa7db246-1577-43b7-a117-c18a73140091@bastelstu.be> <669BE870.2050908@adviesenzo.nl> <b7b47e7a-fc20-4774-bc49-fff271386504@bastelstu.be> <CADK1yXK4bapqAWLZLNk--Fvo87AOv2qbSM1mTn23gU1JSMcL_g@mail.gmail.com> <86eef5d8-6ffc-45e0-8ed6-6201a414cfb7@bastelstu.be> <2C00EB00-0BA4-40F8-92A5-50B49A639AD6@rwec.co.uk> <669D5467.4090103@adviesenzo.nl>
Message-ID: <F38F3E4D-637C-40CC-9BE6-F0A52BD2A34A@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 21 July 2024 19:33:11 BST, Juliette Reinders Folmer <php-internals_nosp=
am@adviesenzo=2Enl> wrote:
>The crux - to me - is that it is an undocumented breaking change, which b=
y definition is a bug=2E

There are two parts of this which are bugs, in my opinion:

- That it wasn't documented, e=2Eg=2E with a line in UPGRADING listing the=
 affected tokens=2E
- That the tokenisation consumes the comment as part of the token, rather =
than just performing a lookahead=2E

One is easily fixed; the other is more subtle, but maybe fixable=2E


>As I've said before, I'm not against changing the tokenization, what I'm =
speaking up about is that it was done in an inconsistent, semi-random and u=
ndocumented way=2E

As others have said, there is nothing unusual in the process that was foll=
owed here=2E A minor change was proposed via Pull Request, discussed with m=
ultiple core contributors, and wasn't deemed significant enough for a wider=
 discussion or RFC=2E

The documentation probably *should* have been caught during that review, b=
ecause it's a common checklist item=2E The behaviour of the token stream co=
uld have been, but we got unlucky and nobody thought of it=2E There's no gu=
arantee that a different process would have done better - there have been c=
hanges which went through a whole RFC process, then a year later someone po=
ints out a flaw that could have been avoided; that's life=2E

Now that we have spotted it, we need to decide what to do=2E

Regards,
Rowan Tommins
[IMSoP]