[PHP-DEV] Re: [VOTE] Recommend PIE and deprecate PECL

Folks, Voting has ended on the RFC to deprecate PECL and adopt PIE as the recommended extension installation tool, and has been accepted, with 36 yes, 0 no, 5 abstain. https://wiki.php.net/rfc/adopt_pie_deprecate_pecl Thank you for reviewing the RFC and voting. Thanks James On Wed, 17 Sept 202

[PHP-DEV] Re: [RFC] [Discussion] Add clamp function

Hi, 2025-08-27 at 15:34, Kyle Katarn wrote: > Hello, > > I handled the feedback received on the draft RCF > https://wiki.php.net/rfc/clamp_v2 > > If I didn't forget anything this should be now ready for discussion. So I > updated its status. > > There is an implementation proposal: > https://git

Re: [PHP-DEV] merging r/w locks

On Fri, Sep 12, 2025, at 23:39, Hans Krentel wrote: > > > > On Tuesday 09 September 2025 10:14:31 (+02:00), Rob Landers wrote: > > > Hi internals, > > > > Is there any hope to have https://github.com/php/php-src/pull/16565 merged > > before 8.5? It's too late to address all the locks, but h

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

> Sebastian Bergmann hat am 11.09.2025 08:33 CEST > geschrieben: > > > Am 10.09.2025 um 15:23 schrieb Jakub Zelenka: > > If __sleep is used to serialize private properties (not all but just > > some), then those property names are stored in the mangled format > > ("\x00" . self::class . "\x0

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi, On Wed, Sep 10, 2025 at 3:23 PM Jakub Zelenka wrote: > Hi, > > On Fri, Sep 5, 2025 at 5:55 PM Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > >> Hello internals, >> >> Following the discussion that started at >> https://externals.io/message/128226#128456 I wrote this RFC to formali

[PHP-DEV] PHP 8.4.13RC1 Ready for testing

PHP 8.4.13RC1 has just been released and may be downloaded from https://downloads.php.net/~calvinb/ Or use the git tag: php-8.4.13RC1 Windows binaries are available at: https://windows.php.net/qa/ Please test it carefully, and report any bugs at https://github.com/php/php-src/issues 8.4.13 sho

Re: [PHP-DEV] Environment Variable based PHP Extension loading

On 12 September 2025 21:13:04 BST, Soner Sayakci wrote: >Hey, > >I would like to load PHP extensions by environment variables in a >containerized environment. All existing solutions are moving files in an >entrypoint and this does not work for read-only containers. Why this? >Extensions like Black

Re: [PHP-DEV] [RFC proposal] Syntactic sugar for array push()

On Sat, Sep 13, 2025 at 1:24 PM Rowan Tommins [IMSoP] wrote: > On 12 September 2025 20:02:04 BST, "Dušan Kreheľ" > wrote: > >[+] array_push > >[-] array_pop > >[-<] array_shift > > > >array_unshift() is a special case of array_merge(), so it would then need > >syntactic sugar for merging arrays,

[PHP-DEV] [Vote] Soft-Deprecate __sleep() and __wakeup()

Hi everyone, A little bit earlier than anticipated but still in line with our policies, I'm opening the vote for the "Soft-Deprecate __sleep() and __wakeup()" RFC: https://wiki.php.net/rfc/soft-deprecate-sleep-wakeup The vote will remain open for 2 weeks and will close at 2025-10-04T00:00:00Z. R

Re: [PHP-DEV] [RFC] [Discussion] Add clamp function

Hello 2025-08-29 at 15:12, Tim Düsterhus wrote: > Hi > > On 8/29/25 04:42, Morgan wrote: > > Another part of the argument is "complexity", as brought up in the > > original proposal. I notice that the offered implementation of this > > function relies entirely on zend_compare(). > > I'm not find

Re: [PHP-DEV] [RFC proposal] Syntactic sugar for array push()

On Friday 12 September 2025 12:19:19 (+02:00), Dušan Kreheľ wrote: > A proposal to add syntactic sugar for array_push() in PHP. > > Syntax: > // now > array_push($array, 1); > > // new syntax > $array[+]=1; // old $array[] = 1; > > Dušan Kreheľ > -- hakre

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

Hi Please find the RFC at: https://wiki.php.net/rfc/rfc_discussion_and_vote And the PR at: https://github.com/php/policies/pull/23 If you followed along the discussion, you might've seen that Larry offered to improve the phrasing of the policy for clarity. This has happened now and I think

[PHP-DEV] merging r/w locks

Hi internals, Is there any hope to have https://github.com/php/php-src/pull/16565 merged before 8.5? It's too late to address all the locks, but having it as part of the ABI would be nice so we can start fixing them for 8.6/9.0. In FrankenPHP, if something takes a lock, it can significantly aff

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi Tim > Hello internals, > > > > Following the discussion that started at > > https://externals.io/message/128226#128456 I wrote this RFC to > > formalize > > our consensus on the topic. > > > > TL;DR, this is about converting the deprecation of __sleep and __wakeup > > to > > a documentation-ba

Re: [PHP-DEV] [RFC] Add pack()/unpack() support for signed integers with specific endianness

Am 16.09.2025 um 13:45 schrieb Alexandre Daubois : > I’d like to present this new RFC. When discussing the issue, we first thought > that the RFC process wasn’t necessary. However, discussions on the PR showed > that selecting new letters for pack and unpack is more challenging than we > initial

Re: [PHP-DEV] Environment Variable based PHP Extension loading

On Friday 12 September 2025 22:13:04 (+02:00), Soner Sayakci wrote: > Hey, > > I would like to load PHP extensions by environment variables in a > containerized environment. All existing solutions are moving files in an > entrypoint and this does not work for read-only containers. Why this?

Re: [PHP-DEV] [RFC] Add pack()/unpack() support for signed integers with specific endianness

Hi, > I'm not sure if “all formatting codes work the same” is still 100% > accurate (due to J and P), but “many differences” is definitely false. > I'm seeing the following differences: > > - J and P might or might not be different. > - e, E, g, and G don't exist in Perl (it would be d<, d>, f<, a

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi Am 2025-09-05 17:53, schrieb Nicolas Grekas: Hello internals, Following the discussion that started at https://externals.io/message/128226#128456 I wrote this RFC to formalize our consensus on the topic. TL;DR, this is about converting the deprecation of __sleep and __wakeup to a docume

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi Am 2025-09-10 18:17, schrieb Nicolas Grekas: 2. The examples are biased. As an example, the initial “User” example has a serialization hook that is completely useless. The other examples try to replicate `__sleep()`'s broken behavior exactly, which seems to be a relevant requirement in t

Re: [PHP-DEV] RFC Karma

Hi Robert On Fri, Sep 12, 2025 at 8:11 PM Robert Wolf wrote: > > [snip] and would like to submit an RFC to that end. > [snip] > My wiki username is "rposky". I have granted you RFC karma. Good luck! Ilija

[PHP-DEV] Re: [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi all, Hello internals, > > Following the discussion that started at > https://externals.io/message/128226#128456 I wrote this RFC to formalize > our consensus on the topic. > > TL;DR, this is about converting the deprecation of __sleep and __wakeup to > a documentation-based soft deprecation: >

Re: [PHP-DEV] [RFC] Add pack()/unpack() support for signed integers with specific endianness

Hi Am 2025-09-17 09:09, schrieb Alexandre Daubois: I'm not sure to exactly understand what you mean. Do you propose to introduce < and > modifiers and deprecate some letters, if I get it right? I'm proposing to introduce the `<` and `>` modifiers, following Perl's lead. This would then allow

[PHP-DEV] Re: [VOTE] Recommend PIE and deprecate PECL

Folks, A polite reminder that the below vote will end soon: https://wiki.php.net/rfc/adopt_pie_deprecate_pecl Voting ends 2025-09-20T09:00:00Z. Thanks James On Sat, 6 Sept 2025, 09:41 James Titcumb, wrote: > Folks, > > I have opened the vote on the "Recommend PIE and deprecate PECL" RFC > >

Re: [PHP-DEV] [RFC] Add pack()/unpack() support for signed integers with specific endianness

Hi Am 2025-09-16 16:50, schrieb Alexandre Daubois: Indeed, it is just that I'm not sure that it is worth adding modifiers support to pack and unpack as with this addition, most (if not all) cases should be covered then. I don't think it is worth blocking more letters that are also incompatibl

Re: [PHP-DEV] [RFC] Add pack()/unpack() support for signed integers with specific endianness

Hi, > > 1. Base Letters Already Taken > > The point of a modifier is to modify something. That means that there > needs to be a “base letter”. The same base letters are also “taken” in > Perl and have the same definition. > > > 2. Parser Architecture Limitations > > That sounds like a simple probl

Re: [PHP-DEV] [RFC] Add pack()/unpack() support for signed integers with specific endianness

Hi Am 2025-09-16 16:10, schrieb Alexandre Daubois: seems. I guess it would be better to have dedicated functions. I don't think it should be included in this RFC, but that is an interesting idea nevertheless. I'd be really interested if someone comes up with an RFC for this feature! A better `

Re: [PHP-DEV] [RFC] Add pack()/unpack() support for signed integers with specific endianness

Hi Am 2025-09-16 13:45, schrieb Alexandre Daubois: Here is the link to the RFC: https://wiki.php.net/rfc/pack-unpack-endianness-signed-integers-support Thank you for the RFC. I'm confused by the “Why Perl's Approach Cannot Be Used in PHP” section. 1. Base Letters Already Taken The point

Re: [PHP-DEV] [RFC] Add pack()/unpack() support for signed integers with specific endianness

Hi Rob, > Thank you for your work on this. Of all the RFCs I've seen in awhile, this > one is one that I'm most excited to see after writing a protobuf > implementation. Happy to see you immediately have a use case in mind while reading this! > If there is one thing I would be over the moon fo

Re: [PHP-DEV] [RFC] Add pack()/unpack() support for signed integers with specific endianness

On Tue, Sep 16, 2025, at 13:45, Alexandre Daubois wrote: > Hello Internals, > > > I’d like to present this new RFC. When discussing the issue, we first thought > that the RFC process wasn’t necessary. However, discussions on the PR showed > that selecting new letters for pack and unpack is more

[PHP-DEV] [RFC] Add pack()/unpack() support for signed integers with specific endianness

Hello Internals, I’d like to present this new RFC. When discussing the issue, we first thought that the RFC process wasn’t necessary. However, discussions on the PR showed that selecting new letters for pack and unpack is more challenging than we initially thought, thus creating an RFC for this ch

[PHP-DEV] PHP 8.5 Branch Cut - 1 Week Warning

Hi internals, This is your one week warning for the PHP 8.5 branch cut. Next Tuesday (September 23) I will be creating the PHP-8.5 branch as part of the packaging of PHP 8.5.0RC1. At that point, master will be for PHP 8.6, and the default will be that changes target PHP 8.6. If patches need to be

[PHP-DEV] PHP 8.3.26RC1 Ready for testing

PHP 8.3.26RC1 has just been released and can be downloaded from: https://downloads.php.net/~jakub/ or https://qa.php.net/ or use the git tag: php-8.3.26RC1 Windows binaries are available at: https://windows.php.net/qa/#php-8.3 Please test it carefully, and report any bugs to https://github.co

Re: [PHP-DEV] [RFC proposal] Syntactic sugar for array push()

On 2025-09-13 22:21, Rowan Tommins [IMSoP] wrote: On 12 September 2025 20:02:04 BST, "Dušan Kreheľ" wrote: Since we have an extremely well-established array_push shorthand, so don't need a new one, we could perhaps have "<" for "at start", and "-" for "pop": $foo[<] = $toUnshift; $shifted = $

Re: [PHP-DEV] Re: Three proposals for PHP 9

On 10/09/2025 20:57, Gregory Magarshak wrote: Hi everyone. Just wanted to follow up on this. Is there any chance of switch_global_context making it into PHP 9? This would be a huge game-changer as e.g. FrankenPHP in worker mode could literally be up to 100x faster than PHP-FPM! But right now, m

Re: [PHP-DEV] [RFC proposal] Syntactic sugar for array push()

On 12 September 2025 20:02:04 BST, "Dušan Kreheľ" wrote: >[+] array_push >[-] array_pop >[-<] array_shift > >array_unshift() is a special case of array_merge(), so it would then need >syntactic sugar for merging arrays, or rather a reserved merge. array_unshift is no more a special case of array_

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi, On Mon, Sep 8, 2025 at 4:48 PM Tim Düsterhus wrote: > I disagree with the phrasing that the RFC passed with a “narrow margin”. > I just updated the wording so it now says: > A recent RFC to deprecate the __sleep() and __wakeup() magic methods in favor of __serialize() and __unserialize() p

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

On Friday 05 September 2025 17:53:20 (+02:00), Nicolas Grekas wrote: > Hello internals, > > Following the discussion that started at > https://externals.io/message/128226#128456 I wrote this RFC to formalize > our consensus on the topic. > > TL;DR, this is about converting the deprecation

Re: [PHP-DEV] merging r/w locks

On Saturday 13 September 2025 00:37:08 (+02:00), Rob Landers wrote: > > > On Fri, Sep 12, 2025, at 23:39, Hans Krentel wrote: > > > > > > > > On Tuesday 09 September 2025 10:14:31 (+02:00), Rob Landers wrote: > > > > > Hi internals, > > > > > > Is there any hope to have https://github.c

Re: [PHP-DEV] Environment Variable based PHP Extension loading

Hi Hans On Fri, Sep 12, 2025 at 11:21 PM Hans Krentel wrote: > > On Friday 12 September 2025 22:13:04 (+02:00), Soner Sayakci wrote: > > > It's already possible to use environment variables in the php.ini like > so: > > > > extension=${PHP_PROFILER} > > > > So it's possible to toggle the ext

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

On Friday 29 August 2025 22:21:41 (+02:00), Tim Düsterhus wrote: > Hi > > The current policy regarding how RFC are discussed and voted on is quite > dated and no longer matches the current accepted practices of the RFC process. > > In the past there were several RFCs with a less-than-ideal

Re: [PHP-DEV] merging r/w locks

On Tuesday 09 September 2025 10:14:31 (+02:00), Rob Landers wrote: > Hi internals, > > Is there any hope to have https://github.com/php/php-src/pull/16565 merged > before 8.5? It's too late to address all the locks, but having it as part of > the ABI would be nice so we can start fixing the

[PHP-DEV] Environment Variable based PHP Extension loading

Hey, I would like to load PHP extensions by environment variables in a containerized environment. All existing solutions are moving files in an entrypoint and this does not work for read-only containers. Why this? Extensions like Blackfire/XDebug/OpenTelemetry/Tideways do not like each to run at t

[PHP-DEV] Re: [RFC proposal] Syntactic sugar for array push()

array_push would only be used if there were a [-] in the code, i.e. a hyphen (or plus for pop()) as pseudo-constant. Practically, it would change today's behavior that returns an error into a correct operation: napísal(a): > A proposal to add syntactic sugar for array_push() in PHP. > > Syntax:

Re: [PHP-DEV] [RFC proposal] Syntactic sugar for array push()

[+] array_push [-] array_pop [-<] array_shift array_unshift() is a special case of array_merge(), so it would then need syntactic sugar for merging arrays, or rather a reserved merge. pi 12. 9. 2025 o 16:23 Rob Landers napísal(a): > > > On Fri, Sep 12, 2025, at 13:06, Dušan Kreheľ wrote: > > Hm

Re: [PHP-DEV] [RFC proposal] Syntactic sugar for array push()

Hm, I didn't know about $array[] = 1;. It would make sense if it were: $a[+] for push() and $a[-] for pop(). pi 12. 9. 2025 o 12:35 Ken Guest napísal(a): > But we already have $array[] = 1; - are you unaware of it or is there > some other benefit to what you are suggesting? > > What might inter

[PHP-DEV] RFC Karma

Hi, I am a software developer from the US. I have been working in PHP for over a decade now and have something to contribute, and would like to submit an RFC to that end. The topic is the addition of a PDO::disconnect function, for which I sent an exploratory email with the subject "[PHP-DEV

Re: [PHP-DEV] [RFC proposal] Syntactic sugar for array push()

On Fri, Sep 12, 2025, at 13:06, Dušan Kreheľ wrote: > Hm, I didn't know about $array[] = 1;. > > It would make sense if it were: $a[+] for push() and $a[-] for pop(). > > pi 12. 9. 2025 o 12:35 Ken Guest napísal(a): >> But we already have $array[] = 1; - are you unaware of it or is there some

Re: [PHP-DEV] [RFC proposal] Syntactic sugar for array push()

But we already have $array[] = 1; - are you unaware of it or is there some other benefit to what you are suggesting? What might interest people would be a syntactic sugar/shorthand for array_pop but I have no idea what that might look like. On Fri, 12 Sept 2025 at 11:21, Dušan Kreheľ wrote: > A

[PHP-DEV] [RFC proposal] Syntactic sugar for array push()

A proposal to add syntactic sugar for array_push() in PHP. Syntax: // now array_push($array, 1); // new syntax $array[+]=1; Dušan Kreheľ

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

On Mon, Sep 8, 2025, at 9:20 AM, Tim Düsterhus wrote: > Hi > > Am 2025-09-05 18:58, schrieb Larry Garfield: >> Proposed language, to turn the whole thing around: >> >> - >> >> An RFC author MAY start a vote at any time, provided that: >> >> * It has been at least two weeks since the last maj

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

On Mon, Sep 8, 2025 at 8:21 PM Nicolas Grekas wrote: > Hello internals, > > Following the discussion that started at > https://externals.io/message/128226#128456 I wrote this RFC to formalize > our consensus on the topic. > > TL;DR, this is about converting the deprecation of __sleep and __wakeup

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi On 9/11/25 18:51, Nicolas Grekas wrote: As a corollary to your message, I'm wondering what would be the earliest we could open the vote? Our policy on the topic says: There'd be a minimum of 2 weeks between when an RFC that touches the language is brought up on this list and when it's voted

[PHP-DEV] PHP 8.5.0beta3 is available for testing

PHP 8.5.0beta3 has just been released and may be downloaded from https://downloads.php.net/~edorian/ Or use the git tag: php-8.5.0beta3 Windows binaries are available at: https://windows.php.net/qa/ Please test it carefully and report any bugs at https://github.com/php/php-src/issues/new?templat

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi Daniel, Thanks for the update. Le lun. 8 sept. 2025 à 19:25, Daniel Scherzer a écrit : > On Mon, Sep 8, 2025 at 8:21 PM Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > >> Hello internals, >> >> Following the discussion that started at >> https://externals.io/message/128226#128456 I

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi Am 2025-09-10 17:39, schrieb Jakub Zelenka: A recent RFC to deprecate the __sleep() and __wakeup() magic methods in favor of __serialize() and __unserialize() passed (18–9), but only just met the required 2/3 majority. Hope it's better! :) Thank you, the updated phrasing is better indeed

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Am 10.09.2025 um 15:23 schrieb Jakub Zelenka: If __sleep is used to serialize private properties (not all but just some), then those property names are stored in the mangled format ("\x00" . self::class . "\x00" prefix). It means to make it compatible in __serialize, the application has to mang

[PHP-DEV] Re: Three proposals for PHP 9

Hi everyone. Just wanted to follow up on this. Is there any chance of switch_global_context making it into PHP 9? This would be a huge game-changer as e.g. FrankenPHP in worker mode could literally be up to 100x faster than PHP-FPM! But right now, most frameworks which benefit from the awesome shar

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi, On Fri, Sep 5, 2025 at 5:55 PM Nicolas Grekas wrote: > Hello internals, > > Following the discussion that started at > https://externals.io/message/128226#128456 I wrote this RFC to formalize > our consensus on the topic. > > TL;DR, this is about converting the deprecation of __sleep and __w

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi, On Tue, Sep 9, 2025 at 3:39 PM Tim Düsterhus wrote: > Hi > > Am 2025-09-08 23:14, schrieb Jakub Zelenka: > > I understand your concern about the complexity but this can apply to > > many > > other parts in php-src. As I'm sure you know, this still wouldn't > > likely to > > be considered as

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi Am 2025-09-08 23:14, schrieb Jakub Zelenka: I understand your concern about the complexity but this can apply to many other parts in php-src. As I'm sure you know, this still wouldn't likely to be considered as a security issue. I've intentionally said “security sensitive”. I believe the

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi, On Mon, Sep 8, 2025 at 10:44 PM Tim Düsterhus wrote: > Hi > > On 9/8/25 17:32, Jakub Zelenka wrote: > > I think the point here was that it was close and the RFC itself was > > Again, a 2/3 majority is *not* close. Twice the number of folks were in > favor than against the RFC. > > I meant cl

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi On 9/8/25 17:32, Jakub Zelenka wrote: I think the point here was that it was close and the RFC itself was Again, a 2/3 majority is *not* close. Twice the number of folks were in favor than against the RFC. misleading and omitted some important points that would like change the final res

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

Hi Am 2025-08-29 22:21, schrieb Tim Düsterhus: Please find the RFC at: https://wiki.php.net/rfc/rfc_discussion_and_vote And the PR at: https://github.com/php/policies/pull/23 I've made some more (major) changes to the PR on Friday and earlier today. Please find the changelog in the RFC itsel

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

Hi Am 2025-09-05 18:58, schrieb Larry Garfield: Proposed language, to turn the whole thing around: - An RFC author MAY start a vote at any time, provided that: * It has been at least two weeks since the last major change. * It has been at least one week since the last minor change. * Ther

Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi, On Mon, Sep 8, 2025 at 4:48 PM Tim Düsterhus wrote: > Hi > > Am 2025-09-05 17:53, schrieb Nicolas Grekas: > > Hello internals, > > > > Following the discussion that started at > > https://externals.io/message/128226#128456 I wrote this RFC to > > formalize > > our consensus on the topic. > >

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

Hi Am 2025-09-08 17:14, schrieb Larry Garfield: Perhaps the latest changes already make the language a little less awkward? It's an improvement, but I think it can still be improved further. It's still very verbose, and not in ways that I feel are necessary. Would you be OK with me PR-ing

Re: [PHP-DEV] mbstring/iconv encoding deprecation

Hello internals, After discussions with RMs the agreement is that the PR [1] can be merged if there is no objection within 1 week. I'll recapitulate some of the history behind that RFC and delay in implementation. The original RFC [2] was approved for PHP 5.6 and slated for removal in PHP 7. (

Re: [PHP-DEV] How to propose additions to PHP downloads page ?

On 7 September 2025 21:07:35 BST, Julian Somesan wrote: >Hello all, > >I am referring to this page >https://www.php.net/downloads.php > >I want to propose some additions to it : > >- I want to use PHP for : Mezio Development >- and "Windows with WSL/AlmaLinux" > >What is the correct procedure fo

[PHP-DEV] How to propose additions to PHP downloads page ?

Hello all, I am referring to this page https://www.php.net/downloads.php I want to propose some additions to it : - I want to use PHP for : Mezio Development - and "Windows with WSL/AlmaLinux" What is the correct procedure for this ? Thanks

Re: [PHP-DEV] PDO\Sqlite: Add transaction mode attribute

Hi, Is there anything I could do here to get this reviewed before the 8.5 release? As mentioned earlier the proposed implementation should not be subject to the feature freeze. Thank you. Samuel On August 12, 2025, "Samuel Štancl" wrote: > By enums

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

On Fri, Sep 5, 2025, at 12:22, Tim Düsterhus wrote: > Hi > > Am 2025-09-04 20:17, schrieb Rob Landers: > >> Specifically “Other RFCs” (i.e. RFCs that do not touch the language, > >> which is not actually defined) “might” (this probably should read > >> “may”) > >> use a “smaller timeframe” that

Re: [PHP-DEV] mbstring/iconv encoding deprecation

On Thursday, 4 September 2025 at 09:10, Andrey Andreev wrote: > Hi! > > All of these were vote-accepted for removal in PHP 7: > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7#iconv_and_mbstring_encoding_ini_directives > But there was an unforseen issue that needed to be resolve

[PHP-DEV] [VOTE] Recommend PIE and deprecate PECL

Folks, I have opened the vote on the "Recommend PIE and deprecate PECL" RFC RFC: https://wiki.php.net/rfc/adopt_pie_deprecate_pecl Discussion: https://news-web.php.net/php.internals/128536 Voting ends 2025-09-20T09:00:00Z. Thanks James

[PHP-DEV] VCS Account Request: alexandredaubois

Contributing to php-src with features and bug fixes

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

On Wed, Sep 3, 2025, at 4:09 PM, Tim Düsterhus wrote: >> The language for the "extending the discussion period" paragraph is highly >> clumsy and confusing. The existence of the last sentence to clarify it is >> evidence of that. I would recommend rewriting it. (I can offer suggestions >> if

Re: [PHP-DEV] mbstring/iconv encoding deprecation

On 04/09/2025 07:44, Jorg Sowa wrote: + enigmatic "all functions that take encoding option use php.internal_encoding as default (e.g. htmlentities/mb_strlen/mb_regex/etc)" This is not very well worded, but I believe what it's saying is that a number of functions have an "encoding" parameter

Re: [PHP-DEV] enum flag backed enum

On 6 September 2025 01:47:35 BST, Rob Landers wrote: > >Interesting... but we don’t really have a way to say that a parameter or >return value must satisfy *any* constraints except that it be of a certain >type. Hmmm, I guess we have "true" and "false" as values that can be >returned/accepted b

[PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()

Hello internals, Following the discussion that started at https://externals.io/message/128226#128456 I wrote this RFC to formalize our consensus on the topic. TL;DR, this is about converting the deprecation of __sleep and __wakeup to a documentation-based soft deprecation: https://wiki.php.net/rf

Re: [PHP-DEV] enum flag backed enum

On Fri, Sep 5, 2025, at 22:01, Rowan Tommins [IMSoP] wrote: > On 4 September 2025 15:50:08 BST, Rob Landers wrote: > >I think this is a fair observation and a fair question; but I think it is > >important not to have "magic". The power-of-two rule is to make it possible > >to work back how $en

Re: [PHP-DEV] enum flag backed enum

On 4 September 2025 15:50:08 BST, Rob Landers wrote: >I think this is a fair observation and a fair question; but I think it is >important not to have "magic". The power-of-two rule is to make it possible to >work back how $enum->value === 15 (0x) even if you are completely new to >the lang

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

Hi Am 2025-09-04 20:17, schrieb Rob Landers: Specifically “Other RFCs” (i.e. RFCs that do not touch the language, which is not actually defined) “might” (this probably should read “may”) use a “smaller timeframe” that “should be at least a week” (i.e. it may also be 2 hours). In other words,

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

Hi Am 2025-09-04 00:14, schrieb Ilija Tovilo: When making non-editorial / non-typographical changes to the normative section of the RFC text (i.e. to the actual proposal, excluding future scope, rejected features and references) the discussion period MUST be extended. It should also be accep

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

Hi Tim On Fri, Aug 29, 2025 at 10:21 PM Tim Düsterhus wrote: > > Please find the RFC at: https://wiki.php.net/rfc/rfc_discussion_and_vote > And the PR at: https://github.com/php/policies/pull/23 Thank you for your initiative to solidify the unwritten rules we've been following for a while. A few

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

On Thu, Sep 4, 2025, at 15:48, Tim Düsterhus wrote: > Hi > > Am 2025-09-04 00:07, schrieb Rob Landers: > > I’m still trying to understand the problem this language is solving, > > can you help me out here? It is incredibly precise and detailed, but > > gets into over-specification, IMHO. Traditi

Re: [PHP-DEV] PDO\Sqlite: Add transaction mode attribute

Hi Matteo, >From reading earlier discussions my understanding is the feature freeze only applies to things that need RFCs. With PRs that add simple constants not necessarily needing an RFC. Personally I think the diff in the linked PR itself matches that description well, while the alternative im

[PHP-DEV] Re: VCS Account Request: alexandredaubois

VCS Account Approved: alexandredaubois approved by ilutov \o/

Re: [PHP-DEV] PDO\Sqlite: Add transaction mode attribute

Hi Samuel, Il 04/09/2025 00:38, Samuel Štancl ha scritto: Hi, Is there anything I could do here to get this reviewed before the 8.5 release? As mentioned earlier the proposed implementation should not be subject to the feature freeze. https://github.com/php/php-src/pull/19317

Re: [PHP-DEV] PDO\Sqlite: Add transaction mode attribute

On 4 September 2025 09:40:46 BST, "Samuel Štancl" wrote: >Hi Matteo, > >>From reading earlier discussions my understanding is the feature freeze >only applies to things that need RFCs. With PRs that add simple >constants not necessarily needing an RFC. > >Personally I think the diff in the linked

Re: [PHP-DEV] VCS Account Request: alexandredaubois

Hi Internals, Le jeu. 4 sept. 2025 à 10:22, Alexandre Daubois a écrit : > > Contributing to php-src with features and bug fixes The page to request the VCS account states that we may add more information to apply, but it doesn’t seem there’s a field for this in the form, so this is a follow-up e

Re: [PHP-DEV] enum flag backed enum

On Wed, Sep 3, 2025, at 7:20 PM, Morgan wrote: > On 2025-09-04 09:23, Marc B. wrote: >>> >>> Attempting to use a backed value that is not a power-of-two would result in >>> a compilation error. Bitwise operations are performed as though they’re >>> performed on a regular integer. >>> >>> What do

Re: [PHP-DEV] enum flag backed enum

On Thu, Sep 4, 2025, at 15:56, Larry Garfield wrote: > On Wed, Sep 3, 2025, at 7:20 PM, Morgan wrote: > > On 2025-09-04 09:23, Marc B. wrote: > >>> > >>> Attempting to use a backed value that is not a power-of-two would result > >>> in a compilation error. Bitwise operations are performed as thoug

[PHP-DEV] [VOTE] Create split as an alias to explode

Hi, folks. I just opened the vote for the Create "split" as an alias to "explode" RFC. RFC: https://wiki.php.net/rfc/create-split-alias-to-explode Discussion: https://news-web.php.net/php.internals/128503 PR: https://github.com/php/php-src/pull/19490 Voting ends 2025-09-19 at 00:00:00 UTC. Than

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

Hi Am 2025-09-04 00:07, schrieb Rob Landers: I’m still trying to understand the problem this language is solving, can you help me out here? It is incredibly precise and detailed, but gets into over-specification, IMHO. Traditionally, PHP policy has leaned towards principle and illustrative exa

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

Hi Am 2025-08-29 22:21, schrieb Tim Düsterhus: Please find the RFC at: https://wiki.php.net/rfc/rfc_discussion_and_vote And the PR at: https://github.com/php/policies/pull/23 I've just made another (major) update to the PR: - Dropped the “Repeated Discussion” sentence, as announced in my rep

Re: [PHP-DEV] VCS Account Request: alexandredaubois

Hi Alexandre On Thu, Sep 4, 2025 at 10:21 AM Alexandre Daubois wrote: > > Contributing to php-src with features and bug fixes Your VCS account was approved. \o/ Thank you for your contributions!

Re: [PHP-DEV] mbstring/iconv encoding deprecation

Hi! All of these were vote-accepted for removal in PHP 7: https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7#iconv_and_mbstring_encoding_ini_directives But there was an unforseen issue that needed to be resolved before that can happen, and it apparently never got fixed. See this thre

[PHP-DEV] mbstring/iconv encoding deprecation

Hello everyone, I'm writing regarding the deprecation of mbstring/iconv encoding that was voted on more than 10 years ago. RFC: https://wiki.php.net/rfc/default_encoding It was accepted that following INI settings were deprecated: "iconv.input_encoding (Default: php.input_encoding) iconv.internal

Re: [PHP-DEV] enum flag backed enum

On 2025-09-04 09:23, Marc B. wrote: Attempting to use a backed value that is not a power-of-two would result in a compilation error. Bitwise operations are performed as though they’re performed on a regular integer. What do you think? I think what we actually would need is an EnumSet which

Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules

On Wed, Sep 3, 2025, at 23:09, Tim Düsterhus wrote: > Hi > > On 9/3/25 22:07, Larry Garfield wrote: > > "If the proposal > > is a repeated discussion of an existing RFC, with or without modification, > > it > > MUST still be announced on the list for discussion." > > > > What does "repeated di

Re: [PHP-DEV] enum flag backed enum

Hi Rob, Am 3. September 2025 22:44:58 MESZ schrieb Rob Landers : >Hello internals, > >I would like to propose a new type of backed enum: flag. This is an >integer-backed enum that requires power-of-two values that can be combined >with the bitwise operators to be used as flags. > >In some core f

  1   2   3   4   5   6   7   8   9   10   >