Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115338
MIME-Version: 1.0
References: <CAFv4g+HRHrvCOTgpbVfCXj06De1kL+1+RwnGgq6tcyLNAtLfQA@mail.gmail.com>
 <CAF+90c8DbBajg7yukYkyXeJp2RU3JngLcr_zJdP=tOw9ebb6ag@mail.gmail.com>
In-Reply-To: <CAF+90c8DbBajg7yukYkyXeJp2RU3JngLcr_zJdP=tOw9ebb6ag@mail.gmail.com>
Date: Wed, 7 Jul 2021 10:47:19 +0100
Message-ID: <CAFv4g+FqBa_09D_qFHu--zWrt2jKi0jhDb=HBduc4Q=h8ntBQw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000551b7305c6856d92"
Subject: Re: [PHP-DEV] [RFC] [VOTE] is_literal
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000551b7305c6856d92
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 7 Jul 2021 at 10:23 am, Nikita Popov <nikita.ppv@gmail.com> wrote:

> The RFC indicates that the impact is minor, but I believe those
> measurements were made with the original version of the RFC, which did no=
t
> try to distinguish literal and non-literal interned strings



Hi Nikita,

The performance test results in the RFC are based on the latest version,
updated on Monday (before the vote started), M=C3=A1t=C3=A9 Kocsis did thes=
e tests
independently to ensure there was no bias from me (my own tests were
roughly the same).

Joe Watkins would be better placed to explain the details of the
implementation.

We have always tried to keep the implementation as simple as possible, but
there were concerns that certain optimisations by the compiler would make
certain strings appear as literals, not in an unsafe way, but in a way that
might be confusing to developers, with the examples being noted in the RFC:

https://wiki.php.net/rfc/is_literal#compiler_optimisations

Thanks,
Craig

--000000000000551b7305c6856d92--