On Wed, Jul 1, 2026 at 10:42 PM Seifeddine Gmati azjezz@carthage.software wrote:
Where exactly did I give you the impression that I think I’m a better
person? We are having a technical discussion; you are turning it
personal.Cheers,
Seifeddine
I am, and I apologize.
On Monday, 22 June 2026 at 14:13, Gina P. Banyard <internals@gpb.moe> wrote:
Hello internals,
It is this time of year again where we proposed a list of deprecations to add in PHP 8.6:
As a reminder, this list has been compiled over the course of the past year by different people.
And as usual, each deprecation will be voted in isolation.
We still have a bit of time anyone else to propose additional deprecations, and if you have write access feel free to add them directly to the RFC.
Please note that with the new RFC policy rules the RFC must be finalized and in a "frozen" state by the 13th of July at the latest.Some deprecations should be non-controversial, others a bit more.
If a deprecation is really controversial, it might warrant its own dedicated RFC or be dropped altogether.
Reminder that there is less than a single week for adding deprecations before the RFC needs to be in a frozen state.
A few people have added new ones and some were sent directly to me which I just added.
I also reordered some of the deprecations to group them together in somewhat more logical places.
If anyone has any issues or additional proposals they can still be added or amended.
If none are added or amended, I will initiate a call to vote next week.
Best regards,
Gina P. Banyard
On 7 July 2026 12:54:29 BST, "Gina P. Banyard" <internals@gpb.moe> wrote:
If anyone has any issues or additional proposals they can still be added or amended.
If none are added or amended, I will initiate a call to vote next week.
I just skimmed through the page, and counted 35 proposals, of which only 8 had any analysis or discussion of the impact on existing code.
Several more have had discussions of their impact in this thread, but the conclusions have not been summarised in the RFC for voters to see.
----
As I stated previously, if the vote is called with the RFC in the current state, I will cast 27 "no" votes, and only examine the remaining 8 proposals in detail.
----
The reason we require votes to pass with a two-thirds majority is to maintain the status quo by default. Changes, whether they are adding features or removing them, need to be weighed on a balance of cost vs benefit.
It is not reasonable to expect every voter to independently research the costs of every proposal. It is up to the person proposing each change to make an honest and informed case for that balance, rather than presenting only advantages or gut feelings.
I urge everyone whose name is on this RFC to review its content with that in mind.
Thanks,
Rowan Tommins
[IMSoP]
On Tuesday, 7 July 2026 at 14:51, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:
On 7 July 2026 12:54:29 BST, "Gina P. Banyard" <internals@gpb.moe> wrote:
>> PHP: rfc:deprecations_php_8_6
>
>If anyone has any issues or additional proposals they can still be added or amended.
>If none are added or amended, I will initiate a call to vote next week.I just skimmed through the page, and counted 35 proposals, of which only 8 had any analysis or discussion of the impact on existing code.
Several more have had discussions of their impact in this thread, but the conclusions have not been summarised in the RFC for voters to see.
----
As I stated previously, if the vote is called with the RFC in the current state, I will cast 27 "no" votes, and only examine the remaining 8 proposals in detail.
----
You are free to do as you please.
The reason we require votes to pass with a two-thirds majority is to maintain the status quo by default. Changes, whether they are adding features or removing them, need to be weighed on a balance of cost vs benefit.
It is not reasonable to expect every voter to independently research the costs of every proposal. It is up to the person proposing each change to make an honest and informed case for that balance, rather than presenting only advantages or gut feelings.
I urge everyone whose name is on this RFC to review its content with that in mind.
There are no guidelines on what constitutes a "impact assessment".
Especially as qualitative assessments or the cost of keeping it in the language seem to not count.
Unless the people that actively care about this provide concrete methods on how RFC authors can do such an assessment that does not require downloading gigabytes (possibly even terabytes) of barely representative OSS code, building an AST or static analysis tool, and then interpreting result in a way that is suitable for the people that care, I will not be engaging in providing metrics for the sake of providing metric that bear no usefulness for certain proposals.
Best regards,
Gina P. Banyard
On 7 July 2026 16:40:00 BST, "Gina P. Banyard" <internals@gpb.moe> wrote:
There are no guidelines on what constitutes a "impact assessment".
Especially as qualitative assessments or the cost of keeping it in the language seem to not count.
I deliberately did not use the words "impact assessment". I said the proposals did not include "any analysis or discussion of the impact on existing code".
I'm not talking about proposals where the discussion of impact doesn't meet some particular threshold. I'm talking about proposals where there's not even a single sentence discussing it. No attempt to think about who it might affect. Not even a wild guess.
I do not think we should be removing features without thinking about who will be affected. I'm honestly shocked that that's a controversial opinion
Regards,
Rowan Tommins
[IMSoP]
My offer to assist with creating some insights into the potential impact of the proposed deprecations still stands. I believe that by strategically using the PHPCompatibility library [1], creating this type of insight should be fairly straight-forward for ~25 out of the current 36 proposals. The only reason I haven’t done so yet, is that it’s pretty time-consuming to run PHPCompatibility over large data sets and there are more things on my to-do list than just this. Side-note: Gina - I do see and appreciate the (hidden) costs of keeping certain features in the language. But costs goes both ways (cost of deprecating something across the ecosystem versus the costs of continued maintenance of the feature in the language). Smile, Juliette 1:
On 7-7-2026 18:28, Rowan Tommins [IMSoP] wrote:
On 7 July 2026 16:40:00 BST, "Gina P. Banyard" [<internals@gpb.moe>](mailto:internals@gpb.moe) wrote:There are no guidelines on what constitutes a "impact assessment". Especially as qualitative assessments or the cost of keeping it in the language seem to not count.I deliberately did not use the words "impact assessment". I said the proposals did not include "any analysis or discussion of the impact on existing code". I'm not talking about proposals where the discussion of impact doesn't meet some particular threshold. I'm talking about proposals where there's not even a single sentence discussing it. No attempt to think about who it might affect. Not even a wild guess. I do not think we should be removing features without thinking about who will be affected. I'm honestly shocked that that's a controversial opinion