Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120692
Message-ID: <CBB64940-DB18-4F48-9B53-9EBBA2012A2D@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E1C5DBBD-2093-4BF9-8DA9-66511EE2E0AB"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Tue, 27 Jun 2023 10:46:54 +0200
In-Reply-To: <63DC7264-4DE9-421B-B69D-469CE34BD6F7@gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: "G. P. B." <george.banyard@gmail.com>
References: <CAFPFaM+2eUsN9YUdUBEyr6XTe7QagyDBS8_F_LZH00ujJM8shw@mail.gmail.com>
 <CAFPFaMLCPQKz+BCPNRs59Bm=Z+5cSch4zbGVxwuSPzxvyWBo+Q@mail.gmail.com>
 <63DC7264-4DE9-421B-B69D-469CE34BD6F7@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate remains of string evaluated code
 assertions
From: claude.pache@gmail.com (Claude Pache)

--Apple-Mail=_E1C5DBBD-2093-4BF9-8DA9-66511EE2E0AB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Le 27 juin 2023 =C3=A0 10:36, Claude Pache <claude.pache@gmail.com> a =
=C3=A9crit :
>=20
>=20
>=20
>> Le 26 juin 2023 =C3=A0 17:06, G. P. B. <george.banyard@gmail.com> a =
=C3=A9crit :
>>=20
>> On Wed, 31 May 2023 at 13:08, G. P. B. <george.banyard@gmail.com> =
wrote:
>>=20
>>> Hello internals,
>>>=20
>>> I would like to start the discussion about deprecating various =
remains
>>> from the now removed string code evaluated assertions functionality =
of
>>> assert().
>>>=20
>>> The RFC is located on the wiki at the following address:
>>> https://wiki.php.net/rfc/assert-string-eval-cleanup
>>>=20
>>> Initially, this was part of the mass PHP 8.3 deprecation RFC, but =
only the
>>> assert_options() function was part of it.
>>>=20
>>=20
>> Head's up, I'm planning on opening the vote on this on Wednesday the =
28th
>> of June.
>>=20
>> Best regards,
>>=20
>> George P. Banyard
>=20
> Hi,
>=20
> Still some points:
>=20
> I don=E2=80=99t see the RFC listed under =
https://wiki.php.net/rfc#under_discussion.
>=20
> The RFC is imprecise in what is meant by =E2=80=9Cdeprecating=E2=80=9D. =
I guess that a deprecation notice (E_DEPRECATED) will be triggered at =
least under the following conditions:
>=20
> * at startup when one of the assert.* setting has not the default =
value;
> * at runtime when `assert_options(...)` is used;
> * at runtime when `ini_set(...)` is used to set an `assert.*` option =
to a non-default value?
>=20
> It is unclear to me what will happen when:
>=20
> * `ini_set(...)` is used to set an `assert.*` option to its default =
value, either as a no-op or not?
>=20
> Moreover, by removing `assert.callback` (and other options), are you =
effectively removing a feature? (I don=E2=80=99t really know, I have =
never considered it even in my worst dreams.) If so, it should be noted =
in a =E2=80=9CBackward Incompatible Changes=E2=80=9D.
>=20
> =E2=80=94Claude
>=20

... and, of course, changing the return value of `assert(...)` from =
`bool` (true) to `void` is also a BC break, (and it is unclear to me =
what is the effective advantage of the break).

=E2=80=94Claude




--Apple-Mail=_E1C5DBBD-2093-4BF9-8DA9-66511EE2E0AB--