Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120691
Message-ID: <63DC7264-4DE9-421B-B69D-469CE34BD6F7@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_5C57628B-27AC-4C1B-981C-707A25BBA622"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Tue, 27 Jun 2023 10:36:59 +0200
In-Reply-To: <CAFPFaMLCPQKz+BCPNRs59Bm=Z+5cSch4zbGVxwuSPzxvyWBo+Q@mail.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>
Subject: Re: [PHP-DEV] [RFC] Deprecate remains of string evaluated code
 assertions
From: claude.pache@gmail.com (Claude Pache)

--Apple-Mail=_5C57628B-27AC-4C1B-981C-707A25BBA622
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> 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

Hi,

Still some points:

I don=E2=80=99t see the RFC listed under =
https://wiki.php.net/rfc#under_discussion.

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:

* 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?

It is unclear to me what will happen when:

* `ini_set(...)` is used to set an `assert.*` option to its default =
value, either as a no-op or not?

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.

=E2=80=94Claude





--Apple-Mail=_5C57628B-27AC-4C1B-981C-707A25BBA622--