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

> 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