On Tuesday 29 July 2025 21:43:39 (+02:00), Larry Garfield wrote:
> On Tue, Jul 29, 2025, at 2:22 PM, Hans Krentel wrote:
> > On Monday 14 July 2025 15:29:31 (+02:00), Larry Garfield wrote:
>
> >> Is their use for quick hacky scripts worth the cost of reserving a
symbol that could be repurpo
On Friday 04 July 2025 14:40:23 (+02:00), Tim Düsterhus wrote:
> Hi
>
> On 7/3/25 18:04, Derick Rethans wrote:
> > The intention behind the filter extension was that admins can set a
> > default filter for *all* data coming in through this `filter.default`
> > setting as a "safe" fallback. Th
On Wed, August 6, 2025 at 17:08 Juliette Reinders Folmer wrote:
> On 6-8-2025 6:21, Theodore Brown wrote:
>> I just analyzed the top 1500 Composer packages for a couple more of the
>> proposed syntax
>> deprecations, and found the following:
>>
>> ## Deprecate non-standard cast names:
>> 197 non-s
On 6-8-2025 6:21, Theodore Brown wrote:
On Thu, July 24, 2025 at 22:47 Juliette Folmer wrote:
On 2-7-2025 21:56, G. P. Banyard wrote:
It is this time of year again where we proposed a list of deprecations to add
in PHP 8.5:
https://wiki.php.net/rfc/deprecations_php_8_5
Just leaving a note
On Wed, August 6, 2025 at 03:09 Christoph M. Becker wrote:
> On 06.08.2025 at 06:21, Theodore Brown wrote:
>
>> I just analyzed the top 1500 Composer packages for a couple more of the
>> proposed syntax
>> deprecations, and found the following:
>>
>> ## Deprecate non-standard cast names:
>> 197 n
On 06.08.2025 at 06:21, Theodore Brown wrote:
> I just analyzed the top 1500 Composer packages for a couple more of the
> proposed syntax
> deprecations, and found the following:
>
> ## Deprecate non-standard cast names:
> 197 non-standard casts in 25 unique packages.
>
> ## Deprecate backticks
On Thu, July 24, 2025 at 22:47 Juliette Folmer wrote:
>> On 2-7-2025 21:56, G. P. Banyard wrote:
>>
>> It is this time of year again where we proposed a list of deprecations to
>> add in PHP 8.5:
>>
>> https://wiki.php.net/rfc/deprecations_php_8_5
>
>
> Just leaving a note here that I find it inc
On Tue, Jul 29, 2025, at 2:22 PM, Hans Krentel wrote:
> On Monday 14 July 2025 15:29:31 (+02:00), Larry Garfield wrote:
>> Is their use for quick hacky scripts worth the cost of reserving a symbol
>> that could be repurposed for something else more generally useful in the
>> future? (Not immedi
On Monday 14 July 2025 15:29:31 (+02:00), Larry Garfield wrote:
> On Mon, Jul 14, 2025, at 5:36 AM, Derick Rethans wrote:
> > On Thu, 3 Jul 2025, Jakub Zelenka wrote:
> >
> >> On Wed, Jul 2, 2025 at 10:00 PM Gina P. Banyard wrote:
> >>
> >> > It is this time of year again where we proposed a
On 29 July 2025 17:23:40 BST, Calvin Buckley wrote:
> I have not changed the vote names since I don't
>know if that will break the existing polls.
I can confirm that that would have broken it.
cheers
Derick
On Jul 25, 2025, at 9:40 AM, Gina P. Banyard wrote:
>
> Hello internals,
>
> As Tim announced a few days ago, I've opened the votes for the deprecations:
> https://wiki.php.net/rfc/deprecations_php_8_5
Heads up, I've adjusted the header name for the driver specific build
flags to change depreca
On Fri, Jul 25, 2025 at 2:41 PM Gina P. Banyard wrote:
> Hello internals,
>
> As Tim announced a few days ago, I've opened the votes for the
> deprecations:
> https://wiki.php.net/rfc/deprecations_php_8_5
>
> Please remember that the wiki is only capable to handle a single vote at a
> time,
> so
Hello internals,
As Tim announced a few days ago, I've opened the votes for the deprecations:
https://wiki.php.net/rfc/deprecations_php_8_5
Please remember that the wiki is only capable to handle a single vote at a time,
so please submit each vote you intend on casting individually.
Best regar
On 2-7-2025 21:56, Gina P. Banyard wrote:
Hello internals,
It is this time of year again where we proposed a list of deprecations to add
in PHP 8.5:
https://wiki.php.net/rfc/deprecations_php_8_5
As a reminder, this list has been compiled over the course of the past year by
various different
Hi
Am 2025-07-02 21:56, schrieb Gina P. Banyard:
https://wiki.php.net/rfc/deprecations_php_8_5
Gina asked me to announce the plan to start the vote for her. Except for
the "Deprecate using values null as an array offset and when calling
array_key_exists()" proposal (which originally was the
On Tue, July 8, 2025 at 06:35 Christoph M. Becker wrote:
> On 08.07.2025 at 01:30, Theodore Brown wrote:
>
>> I believe Derick was commenting specifically on using separate tags
>> interleaved around
>> each switch, case, break, and endswitch statement (which there are no plans
>> to deprecate)
> Le 10 juil. 2025 à 13:18, Gina P. Banyard a écrit :
>
> On Wednesday, 9 July 2025 at 22:26, Claude Pache
> wrote:
>> Hi,
>>
>> A possible reason for wanting to use the non-canonical names in settype(),
>> is that those names are returned by gettype(). Fictional example (not
>> intended t
On 2025-07-03 20:34, Morgan wrote:
On 2025-07-03 07:56, Gina P. Banyard wrote:
> Deprecate using values of type null and bool as array offsets and
when calling array_key_exists()
Still curious about this. What have you got against
$branch = [false => $fail, true => $pass];
or
$taken = $b
>
> > Deprecate the __sleep() and __wakeup() magic methods
>
> I'm not sure about this one. I don't think it's worth it. It's just an
> unnecessary BC break IMHO. I would also consider more ext/standard thing
> rather than language.
>
I agree with Jakub here, __sleep and __wakeup are just fine. Ye
On Mon, Jul 14, 2025, at 5:36 AM, Derick Rethans wrote:
> On Thu, 3 Jul 2025, Jakub Zelenka wrote:
>
>> On Wed, Jul 2, 2025 at 10:00 PM Gina P. Banyard wrote:
>>
>> > It is this time of year again where we proposed a list of
>> > deprecations to add in PHP 8.5:
>> >
>> > https://wiki.php.net/rfc
Hi
Am 2025-07-10 15:00, schrieb Christoph M. Becker:
Each PHP version is supported for 4 years by the PHP project [1], thus
giving folks at least 4 years to handle each deprecation until they
are
forced to upgrade to a supported PHP version.
That point is moot for a lot of software where the
On Fri, 4 Jul 2025, Tim Düsterhus wrote:
> On 7/3/25 18:04, Derick Rethans wrote:
>
> > The intention behind the filter extension was that admins can set a
> > default filter for *all* data coming in through this
> > `filter.default` setting as a "safe" fallback. That could/should
> > probably
On Thu, 3 Jul 2025, Jakub Zelenka wrote:
> On Wed, Jul 2, 2025 at 10:00 PM Gina P. Banyard wrote:
>
> > It is this time of year again where we proposed a list of
> > deprecations to add in PHP 8.5:
> >
> > https://wiki.php.net/rfc/deprecations_php_8_5
>
> Here are few notes on the ones that I d
On Wed, 2 Jul 2025, Kamil Tekiela wrote:
> On Wed, Jul 2, 2025, 21:58 Gina P. Banyard wrote:
>
> > Some should be non-controversial, others a bit more. If such, they
> > might warrant their own dedicated RFC, or be dropped from the
> > proposal altogether.
>
> ext/filter deprecations
>
> As m
On 10.07.2025 at 14:06, Tim Düsterhus wrote:
> Am 2025-07-09 12:34, schrieb Christoph M. Becker:
>
>> That *might* give users only a year to fix the deprecated features, what
>> might not match everybody's pace, though.
>
> Each PHP version is supported for 4 years by the PHP project [1], thus
>
Hi
Am 2025-07-09 12:34, schrieb Christoph M. Becker:
The RFC at hand states:
| The RFC proposes to deprecate the listed functionality in PHP 8.5 and
| remove it in PHP 9 (except where otherwise noted).
That *might* give users only a year to fix the deprecated features,
what
might not match e
On Wednesday, 9 July 2025 at 22:26, Claude Pache wrote:
> Hi,
>
> A possible reason for wanting to use the non-canonical names in settype(), is
> that those names are returned by gettype(). Fictional example (not intended
> to be reasonable, only illustrative):
>
> ```php
> function settype_fro
On 7/10/2025 12:23 AM, Claude Pache wrote:
Le 9 juil. 2025 à 14:21, Gina P. Banyard a écrit :
On Wednesday, 9 July 2025 at 08:17, Daikaras
wrote:
We propose to deprecate the following non-standard cast names:
*
|(integer)|
*
|(boolean)|
*
|(double)|
*
|(binary)|
H
> Le 9 juil. 2025 à 14:21, Gina P. Banyard a écrit :
>
> On Wednesday, 9 July 2025 at 08:17, Daikaras wrote:
>>
>>> We propose to deprecate the following non-standard cast names:
>>>
>>> (integer)
>>> (boolean)
>>> (double)
>>> (binary)
>> Hello,
>>
>> Just wondering is this going to affect
On Wednesday, 9 July 2025 at 08:17, Daikaras wrote:
>> We propose to deprecate the following non-standard cast names:
>>
>> - (integer)
>> - (boolean)
>> - (double)
>> - (binary)
>
> Hello,
>
> Just wondering is this going to affect `settype()` function? There is already
> some disparity
On 06.07.2025 at 19:16, Tim Düsterhus wrote:
> Nevertheless I found it important to point out that the deprecation
> itself is not a breaking change, since it is a common theme that folks
> incorrectly claim that "PHP X.Y broke my code", when it's just some
> deprecation messages being emitted. Th
We propose to deprecate the following non-standard cast names:
*
|(integer)|
*
|(boolean)|
*
|(double)|
*
|(binary)|
Hello,
Just wondering is this going to affect `settype()` function? There is
already some disparity in that `settype()` supports
`integer/boolean/double`
On 08.07.2025 at 01:30, Theodore Brown wrote:
>>> Almost all of these were quickly fixed by sending a pull request.
>>
>> See https://externals.io/message/126000, in particular Derick's reply.
>
> I believe Derick was commenting specifically on using separate tags
> interleaved around
> each sw
uly 2, 2025 10:56 PM
To: PHP internals
Subject: [PHP-DEV] [RFC] Deprecations for PHP 8.5
Hello internals,
It is this time of year again where we proposed a list of deprecations to add
in PHP 8.5:
https://wiki.php.net/rfc/deprecations_php_8_5
As a reminder, this list has been compiled over the course
Apologies for the duplicate; I missed CCing Internals previously.
On Mon, July 7, 2025 at 13:53 Niels Dossche wrote:
>>> There are a few things I will vote no for:
>>>
>>> * Deprecate semicolon after case in switch statement.
>>> People seem to use this and it doesn't seem harmful to have. Just
On 07/07/2025 20:55, Theodore Brown wrote:
> On Fri, July 4, 2025 at 01:01 Niels Dossche wrote:
>
>> There are a few things I will vote no for:
>>
>> * Deprecate semicolon after case in switch statement.
>> People seem to use this and it doesn't seem harmful to have. Just because
>> you don't l
On 07/07/2025 21:19, Theodore Brown wrote:
> On Mon, July 7, 2025 at 11:03 Niels Dossche wrote:
>> You're allowed to do $array[null], $array[3.14], etc... and the key will
>> coerce.
>> I expect array_key_exists() to behave the same way as keys on array accesses
>> do.
>
> I'm confused what you
On Mon, July 7, 2025 at 11:03 Niels Dossche wrote:
>>> There are a few things I will vote no for:
>>>
>>> [...]
>>>
>>> * Deprecate using values of type null and bool as array offsets and when
>>> calling array_key_exists()
>>> Deprecating this would make the language more inconsistent by allowin
On Fri, July 4, 2025 at 01:01 Niels Dossche wrote:
> There are a few things I will vote no for:
>
> * Deprecate semicolon after case in switch statement.
> People seem to use this and it doesn't seem harmful to have. Just because
> you don't like it doesn't mean we should yeet it.
Can you poi
On 07/07/2025 17:48, Gina P. Banyard wrote:
> On Friday, 4 July 2025 at 08:04, Niels Dossche
> wrote:
>
>> Secondly, I'm tired of having to deal with useless deprecation messages.
>> A lot of deprecation messages are completely useless for developers because
>> they do not point to a reason or
On Monday, 7 July 2025 at 16:46, Eric Norris wrote:
> > ** Deprecate the error_prepend_string and error_append_string INI directives
> > Why is that of questionable use? Why is "this is a development and
> > debugging feature" considered a valid reason to get rid of something? It
> > allows pro
On Friday, 4 July 2025 at 08:04, Niels Dossche wrote:
> Hi
>
> First of all, that's a huge list of deprecations and I think we should tone
> down on that.
> Especially if a feature still has a purpose and is not harmful or buggy, then
> we should probably consider not deprecating it.
The list
> ** Deprecate the error_prepend_string and error_append_string INI directives
>Why is that of questionable use? Why is "this is a development and
> debugging feature" considered a valid reason to get rid of something? It
> allows prominently displaying issues in development when they would b
On Friday, 4 July 2025 at 22:52, Peter Kokot wrote:
> I'd also suggest deprecating building ext/readline with the Readline library
> and
> ext/dba with the GDBM library.
>
> These two libraries are released under the GPL-3 license, which is not
> compatible with PHP. In practice this means that
On Thursday, 3 July 2025 at 17:05, Derick Rethans wrote:
> On Wed, 2 Jul 2025, Gina P. Banyard wrote:
>
> > Some should be non-controversial, others a bit more. If such, they
> > might warrant their own dedicated RFC, or be dropped from the proposal
> > altogether.
>
>
> The changes to filter
On Jul 7, 2025, at 12:22 PM, Gina P. Banyard wrote:
>
> On Wednesday, 2 July 2025 at 21:57, Calvin Buckley wrote:
>>
>> Thanks for reminding me I should dust off my proposal for cleaning up
>> ODBC driver support. Might be a good idea to put it to a vote...
>>
>> https://github.com/php/php-src
On Wednesday, 2 July 2025 at 21:57, Calvin Buckley wrote:
> On Jul 2, 2025, at 4:56 PM, Gina P. Banyard intern...@gpb.moe wrote:
>
> > Hello internals,
> >
> > It is this time of year again where we proposed a list of deprecations to
> > add in PHP 8.5:
> >
> > https://wiki.php.net/rfc/deprec
On Wednesday, 2 July 2025 at 21:47, Larry Garfield
wrote:
> For the DB-specific PDO constants, am I correct that all of those constants
> and methods already have equivalents in their respective driver classes? (If
> so, please state that explicitly.)
I have added the corresponding constant/me
On Thursday, 3 July 2025 at 15:49, Ilija Tovilo wrote:
> Hi everyone
>
> On Wed, Jul 2, 2025 at 9:58 PM Gina P. Banyard intern...@gpb.moe wrote:
>
> > It is this time of year again where we proposed a list of deprecations to
> > add in PHP 8.5:
> >
> > https://wiki.php.net/rfc/deprecations_ph
Hey Tim,
On 6.7.2025 15:35:16, Tim Düsterhus wrote:
Hi
Since this is a recurring thing, I feel compelled to point out
terminology: A deprecation in itself is not a breaking change.
Let me disagree with this. Yes, a deprecation in *itself* doesn't break
running code. However it is both a) an
Hey,
On 4.7.2025 09:01:52, Niels Dossche wrote:
Hi
First of all, that's a huge list of deprecations and I think we should tone
down on that.
Especially if a feature still has a purpose and is not harmful or buggy, then
we should probably consider not deprecating it.
Yeah, I agree. The list
Hi
On 7/3/25 16:45, Ilija Tovilo wrote:
Deprecate passing spl_autoload_call() to spl_autoload_unregister()
Is such a check actually useful? We can prevent
spl_autoload_unregister(spl_autoload_call(...)), but we can't prevent
spl_autoload_unregister(fn($c) => spl_autoload_call($c)). It seems
ve
Hi
On 7/4/25 09:01, Niels Dossche wrote:
First of all, that's a huge list of deprecations and I think we should tone
down on that.
Especially if a feature still has a purpose and is not harmful or buggy, then
we should probably consider not deprecating it.
It's a long list, but many of the d
On 2025-07-04 19:38, Alexandru Pătrănescu wrote:
I'm thinking about constructors usually like this:
They are functions that are invoked statically (using the `new` keyword)
on the class before the object is created, and they execute on instance
level, after the object is created.
They are ca
On Jul 4, 2025, at 6:52 PM, Peter Kokot wrote:
>
> I'd also suggest deprecating building ext/readline with the Readline library
> and
> ext/dba with the GDBM library.
>
> These two libraries are released under the GPL-3 license, which is not
> compatible with PHP. In practice this means that PH
On Fri, Jul 4, 2025 at 3:17 PM Ilija Tovilo wrote:
> Hi everyone
>
> On Wed, Jul 2, 2025 at 9:58 PM Gina P. Banyard wrote:
> >
> > It is this time of year again where we proposed a list of deprecations
> to add in PHP 8.5:
> >
> > https://wiki.php.net/rfc/deprecations_php_8_5
>
> > Deprecate Ref
On Wed, 2 Jul 2025 at 22:40, Gina P. Banyard wrote:
> Hello internals,
>
> It is this time of year again where we proposed a list of deprecations to
> add in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5
>
> As a reminder, this list has been compiled over the course of the past
> yea
On 3 July 2025 17:04:59 BST, Derick Rethans wrote:
>The intention behind the filter extension was that admins can set a
>default filter for *all* data coming in through this `filter.default`
>setting as a "safe" fallback. That could/should probably even be a
>filter that just makes all data "☺"
Hi
On 7/3/25 18:04, Derick Rethans wrote:
The intention behind the filter extension was that admins can set a
default filter for *all* data coming in through this `filter.default`
setting as a "safe" fallback. That could/should probably even be a
Genuine question: Is that *intention* documente
> Le 2 juil. 2025 à 21:56, Gina P. Banyard a écrit :
>
> It is this time of year again where we proposed a list of deprecations to add
> in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5
Hi,
To reduce noise, I’ll be short.
General remark: For each deprecation, please research f
On Wed, Jul 2, 2025 at 11:00 PM Gina P. Banyard wrote:
> Hello internals,
>
> It is this time of year again where we proposed a list of deprecations to
> add in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5
>
On the topic of deprecating `__construct()` in interfaces:
I'm thinking
Hi
First of all, that's a huge list of deprecations and I think we should tone
down on that.
Especially if a feature still has a purpose and is not harmful or buggy, then
we should probably consider not deprecating it.
Secondly, I'm tired of having to deal with useless deprecation messages.
A l
On Wed, Jul 2, 2025 at 10:00 PM Gina P. Banyard wrote:
> Hello internals,
>
> It is this time of year again where we proposed a list of deprecations to
> add in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5
>
>
Looking at it again I think this huge deprecation RFC is not the right
ap
On Wed, 2 Jul 2025, Gina P. Banyard wrote:
> Some should be non-controversial, others a bit more. If such, they
> might warrant their own dedicated RFC, or be dropped from the proposal
> altogether.
The changes to filter continue to undermine what the extension was meant
to do. The filter.defa
Hi everyone
On Wed, Jul 2, 2025 at 9:58 PM Gina P. Banyard wrote:
>
> It is this time of year again where we proposed a list of deprecations to add
> in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5
Thanks for the bulk RFC. Some thoughts.
> Deprecate __construct() and __destruct()
Hi,
On Wed, Jul 2, 2025 at 10:00 PM Gina P. Banyard wrote:
> Hello internals,
>
> It is this time of year again where we proposed a list of deprecations to
> add in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5
>
>
Here are few notes on the ones that I don't agree with:
> Deprecat
On 2 July 2025 20:56:12 BST, "Gina P. Banyard" wrote:
>Hello internals,
>
>It is this time of year again where we proposed a list of deprecations to add
>in PHP 8.5:
>
>https://wiki.php.net/rfc/deprecations_php_8_5
For FILTER_CALLBACK, I can see it being useful in the extended mode of
filter_va
On 2025-07-03 07:56, Gina P. Banyard wrote:
Hello internals,
Some should be non-controversial, others a bit more.
If such, they might warrant their own dedicated RFC, or be dropped from the
proposal altogether.
Best regards,
Gina P. Banyard
Just skimming and saw
> Deprecate using values o
On Wed, Jul 2, 2025, 21:58 Gina P. Banyard wrote:
> Hello internals,
>
> It is this time of year again where we proposed a list of deprecations to
> add in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5
>
> As a reminder, this list has been compiled over the course of the past
> year
On Jul 2, 2025, at 4:56 PM, Gina P. Banyard wrote:
>
> Hello internals,
>
> It is this time of year again where we proposed a list of deprecations to add
> in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5
>
> As a reminder, this list has been compiled over the course of the past
On Wed, Jul 2, 2025, at 2:56 PM, Gina P. Banyard wrote:
> Hello internals,
>
> It is this time of year again where we proposed a list of deprecations
> to add in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5
>
> As a reminder, this list has been compiled over the course of the past
>
Hello internals,
It is this time of year again where we proposed a list of deprecations to add
in PHP 8.5:
https://wiki.php.net/rfc/deprecations_php_8_5
As a reminder, this list has been compiled over the course of the past year by
various different people.
And as usual, each deprecation will
72 matches
Mail list logo
