> Le 27 juin 2023 à 10:36, Claude Pache <claude.pa...@gmail.com> a écrit : > > > >> Le 26 juin 2023 à 17:06, G. P. B. <george.bany...@gmail.com> a écrit : >> >> On Wed, 31 May 2023 at 13:08, G. P. B. <george.bany...@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
