Re: [RFC] Deprecate remains of string evaluated code assertions

> Le 27 juin 2023 à 10:36, Claude Pache <claude.pache@gmail.com> a écrit : > > > >> Le 26 juin 2023 à 17:06, G. P. B. <george.banyard@gmail.com> a écrit : >> >> On Wed, 31 May 2023 at 13:08, G. P. B. <george.banyard@gmail.com> wrote: >> >>> Hello internals, >>> >>> I would like to start the discussion about deprecating various remains >>> from the now removed string code evaluated assertions functionality of >>> assert(). >>> >>> The RFC is located on the wiki at the following address: >>> https://wiki.php.net/rfc/assert-string-eval-cleanup >>> >>> Initially, this was part of the mass PHP 8.3 deprecation RFC, but only the >>> assert_options() function was part of it. >>> >> >> Head's up, I'm planning on opening the vote on this on Wednesday the 28th >> of June. >> >> Best regards, >> >> George P. Banyard > > Hi, > > Still some points: > > I don’t see the RFC listed under > https://wiki.php.net/rfc#under_discussion. > > The RFC is imprecise in what is meant by “deprecating”. 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’t really know, I have never considered it even in my > worst dreams.) If so, it should be noted in a “Backward Incompatible Changes”. > > —Claude > ... 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). —Claude