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
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
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:
>
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
>
>
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
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:
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
VCS Account Approved: alexandredaubois approved by ilutov \o/
Folks,
Quick update on this.
I've amended the wording slightly to be more general about linking to docs;
the official docs can be updated accordingly and IMO doesn't need an RFC;
that will be done in time!
Assuming no further feedback/discussion, I'll start the vote on or shortly
after 6th Septe
I forgot to specify my username. Sorry. Haha
It's cviniciussdias
Thank you.
On 29/07/2025 19:34, Niels Dossche wrote:
> Hi internals
>
> I'm opening the vote on "Cookies Having Independent Partitioned State
> (CHIPS)".
> RFC URL: https://wiki.php.net/rfc/chips
> The vote runs from now until 2025-08-12 20:00 GMT+2 (18:00 UTC time).
>
> Kind regards
> Niels
>
Hi interna
> Given that this cannot be included in PHP 8.5, I would suggest waiting at
> least a few weeks before starting the vote - some people (myself definitely
> included) may not have had a chance to review the RFC because of the work
> surrounding trying to finalize and implement things before the P
On Tue, Aug 12, 2025 at 4:35 AM Alexandre Daubois <
alex.daubois+...@gmail.com> wrote:
> Hi Internals,
>
> This is a friendly reminder that this RFC has been under discussion
> for a couple of weeks. Today marks two weeks since the announcement of
> this RFC. After some uneventful discussions, I a
Hi Internals,
This is a friendly reminder that this RFC has been under discussion
for a couple of weeks. Today marks two weeks since the announcement of
this RFC. After some uneventful discussions, I am wondering how we
should proceed now. Would you like to continue the discussion, or
perhaps init
On Thu, Jul 24, 2025 at 2:06 PM Daniel Scherzer
wrote:
> Hi internals,
>
> Voting is now open for this RFC.
>
> * RFC: https://wiki.php.net/rfc/deprecated_traits
> * Discussion thread: https://externals.io/message/127912
>
> Voting will end 2025-08-07 at end-of-day UTC.
>
> -Daniel
>
I have clos
On Thu, Jul 24, 2025 at 2:05 PM Daniel Scherzer
wrote:
> Hi internals,
>
> Voting is now open for this RFC.
>
> * RFC: https://wiki.php.net/rfc/filter_throw_on_failure
> * Discussion thread: https://externals.io/message/127911
>
> Voting will end 2025-08-07 at end-of-day UTC.
>
> -Daniel
>
I hav
> 21. 7. 2025 v 19:31, Jiří Pudil :
>
> Hi internals,
>
> after two weeks of a rather uneventful discussion, I’ve opened the vote for
> my RFC proposing to extend the target of the #[\Override] attribute to
> properties. The vote will run for two weeks, until August 5, 00:00:00 UTC.
>
> RFC:
On 7/29/25 8:11 PM, Jonathan Vollebregt wrote:
I came across this edge case today:
I was just informed that my first message ended up in someone's spam
box, not sure why. I'm bumping without content in case it's happening to
more people and the link tripped something.
On Thu, Jul 31, 2025 at 5:20 PM Daniel Scherzer
wrote:
> PHP 8.5.0alpha4 has just been released and may be downloaded from
> https://downloads.php.net/~daniels/
>
> Or use the git tag: php-8.5.0alpha4
>
> ...
>
> Thank you, and happy testing!
>
> Regards,
> Daniel Scherzer, Volker Dusch, and Pier
On Thu, Jul 17, 2025 at 9:21 AM Daniel Scherzer
wrote:
> Hi internals,
>
> Voting is now open for this RFC.
>
> * RFC: https://wiki.php.net/rfc/delayedtargetvalidation_attribute
> * Discussion thread: https://externals.io/message/127702
>
> Voting will end 2025-07-31 at end-of-day UTC.
>
> -Danie
Just want to remind you about the topic.
If everyone has no objections I'll create an RFC during the next week.
--
Best regards,
Dmitrii Derepko.
@xepozz
Hi, Internals!
Unfortunately, RFC didn't pass the Voting stage:
18 people voted against, while only 6 voted for.
Thank you for your attention.
--
Best regards,
Dmitrii Derepko.
@xepozz
> I would like to present the RFC to add the
> "is_representable_as_float()" and "is_representable_as_int()"
> functions. These functions provide developers with a way to check
> whether values can be losslessly converted between integer and
> floating-point representations.
>
> https://wiki.php.ne
On Mon, Jul 28, 2025 at 7:34 PM Volker Dusch wrote:
>
> Hi internals,
>
> Any RFCs that are trying to target PHP 8.5 need to have completed voting
> by August 12, 2 weeks from tomorrow. This lets us finalize the list of the
> biggest features that need to be merged. For smaller features that do no
On Sat, Jul 5, 2025 at 4:23 PM Daniel Scherzer
wrote:
> Hi internals,
>
> I'd like to start the discussion for a new RFC about adding
> a FILTER_THROW_ON_FAILURE flag to the filter extension.
>
> * RFC: https://wiki.php.net/rfc/filter_throw_on_failure
> * Implementation: https://github.com/php/ph
On Sat, Jul 5, 2025 at 4:30 PM Daniel Scherzer
wrote:
> Hi internals,
>
> I'd like to start the discussion for a new RFC about adding support for
> #[\Deprecated] on traits.
>
> * RFC: https://wiki.php.net/rfc/deprecated_traits
> * Implementation: https://github.com/php/php-src/pull/19045
>
> --D
On Fri, Jul 4, 2025 at 11:01 PM Jakub Zelenka wrote:
> Hello,
>
> I would like introduce and open discussion for RFC proposing the addition
> of JSON Schema validation support to JSON extension:
>
> https://wiki.php.net/rfc/json_schema_validation
>
> If this is successful, it should be just the f
Le lun. 21 juil. 2025 à 20:23, Daniel Scherzer
a écrit :
> On Thu, Jul 17, 2025 at 9:21 AM Daniel Scherzer <
> daniel.e.scher...@gmail.com> wrote:
>
>> Hi internals,
>>
>> Voting is now open for this RFC.
>>
>> * RFC: https://wiki.php.net/rfc/delayedtargetvalidation_attribute
>> * Discussion thre
On Thu, Jul 17, 2025 at 9:21 AM Daniel Scherzer
wrote:
> Hi internals,
>
> Voting is now open for this RFC.
>
> * RFC: https://wiki.php.net/rfc/delayedtargetvalidation_attribute
> * Discussion thread: https://externals.io/message/127702
>
> Voting will end 2025-07-31 at end-of-day UTC.
>
> -Danie
Hi everyone,
On 19.06.25 16:08, Marc Bennewitz wrote:
Hi,
During the discussion about the year 2038 issue it turned out that
maybe it's time to drop support for 32-bit of PHP completely.
Based on that I have created an RFC to deprecate 32-bit build in
8.next and drop support for it in 9.
On Sat, Jul 19, 2025, at 03:04, Claude Pache wrote:
>
>
>
>> Le 19 juil. 2025 à 00:41, Rob Landers a écrit :
>>
>> The original author (Nikita) suggested that there's nothing in the original
>> design that precludes accessors -- and highlights languages where there are
>> both and they are
> Le 19 juil. 2025 à 00:41, Rob Landers a écrit :
>
> The original author (Nikita) suggested that there's nothing in the original
> design that precludes accessors -- and highlights languages where there are
> both and they are doing just fine more than 5 years later.
Hi Rob,
It is indeed e
On Fri, Jul 18, 2025, at 21:43, Eric Norris wrote:
> Nick, Larry,
>
> On Fri, Jul 18, 2025 at 2:01 PM Nicolas Grekas
> mailto:nicolas.grekas%2b...@gmail.com>> wrote:
> >
> >
> >
> > Le ven. 18 juil. 2025 à 18:32, Tim Düsterhus a écrit :
> >>
> >> Hi
> >>
> >> On 7/17/25 18:26, Larry Garfield wr
Nick, Larry,
On Fri, Jul 18, 2025 at 2:01 PM Nicolas Grekas
wrote:
>
>
>
> Le ven. 18 juil. 2025 à 18:32, Tim Düsterhus a écrit :
>>
>> Hi
>>
>> On 7/17/25 18:26, Larry Garfield wrote:
>> > Given the lack of consensus both here and in off-list discussions on how
>> > to handle get hooks, we hav
On Fri, Jul 18, 2025, at 11:29 AM, Tim Düsterhus wrote:
>> // New code in 8.5:
>>
>> $p = new PositivePoint(3, 4);
>> $p2 = clone($p, ['x' => -10]);
>
> This is not legal code in PHP 8.5. Clone-with respects visibility and
> since your asymmetric visibility RFC included the change, you are
> p
Le ven. 18 juil. 2025 à 18:32, Tim Düsterhus a écrit :
> Hi
>
> On 7/17/25 18:26, Larry Garfield wrote:
> > Given the lack of consensus both here and in off-list discussions on how
> to handle get hooks, we have done the following:
> >
> > * Split the RFC into two sections, one for get, one for s
Hi
On 7/17/25 18:26, Larry Garfield wrote:
Given the lack of consensus both here and in off-list discussions on how to
handle get hooks, we have done the following:
* Split the RFC into two sections, one for get, one for set.
* Expanded and refined the examples for both. The implementation is
On Sat, Jun 7, 2025, at 11:16 PM, Larry Garfield wrote:
> As Nick has graciously provided an implementation, we would like to
> open discussion on this very small RFC to allow `readonly` on backed
> properties even if they have a hook defined.
>
> https://wiki.php.net/rfc/readonly_hooks
"Very sm
Hi
Am 2025-07-16 08:13, schrieb Adam Cable:
This was declined with 6 votes to 11.
Thanks to everyone for voting.
Really appreciate everything that the custodians of PHP do to keep the
language moving forward :)
Even though the RFC was ultimately declined, I'd like to send my note of
appreciat
On Tue, Jul 1, 2025 at 8:01 AM Adam Cable wrote:
> Hi,
>
> Voting just opened on the "str_icontains" RFC.
>
> Please find the following resources:
>
> RFC: https://wiki.php.net/rfc/str_icontains
> Discussion: https://externals.io/message/127667
> PR: https://github.com/php/php-src/pull/18705
>
>
On Tue, Jun 17, 2025 at 4:26 PM Daniel Scherzer
wrote:
> Hi internals,
>
> I'd like to start the discussion for a new RFC about adding a
> `#[\DelayedTargetValidation]` attribute.
>
> * RFC: https://wiki.php.net/rfc/delayedtargetvalidation_attribute
> * Implementation: https://github.com/php/php-
On Thu, 3 Jul 2025 at 00:26, Andreas Hennings wrote:
>
> This topic was discussed in the past as "Declaration-aware
> attributes", and mentioned in the discussion to "Amendments to
> Attributes".
> I now want to propose a close-to-RFC iteration of this.
> (I don't have RFC Karma, my wiki account i
On Sun, Jul 6, 2025 at 5:48 AM Tim Düsterhus wrote:
> Hi
>
> On 7/5/25 00:49, Daniel Scherzer wrote:
> > If there is no further feedback, I intend to start a vote in a few days.
>
> Looking at your #[\Deprecated] for traits RFC
> (https://externals.io/message/127912):
>
> How will #[\DelayedTarge
Hi
On 7/5/25 00:49, Daniel Scherzer wrote:
If there is no further feedback, I intend to start a vote in a few days.
Looking at your #[\Deprecated] for traits RFC
(https://externals.io/message/127912):
How will #[\DelayedTargetValidation] interact with the `validator` of
`zend_internal_attr
On Sat, Jul 5, 2025, at 21:53, Daniel Scherzer wrote:
> On Fri, Jul 4, 2025 at 4:50 PM Rob Landers wrote:
>> __
>>
>> On Sun, Jun 22, 2025, at 22:00, Daniel Scherzer wrote:
>>> On Tue, Jun 17, 2025 at 4:26 PM Daniel Scherzer
>>> wrote:
Hi internals,
I'd like to start the discuss
On Fri, Jul 4, 2025 at 4:50 PM Rob Landers wrote:
>
> On Sun, Jun 22, 2025, at 22:00, Daniel Scherzer wrote:
>
> On Tue, Jun 17, 2025 at 4:26 PM Daniel Scherzer <
> daniel.e.scher...@gmail.com> wrote:
>
> Hi internals,
>
> I'd like to start the discussion for a new RFC about adding a
> `#[\Delaye
On Sun, Jun 22, 2025, at 22:00, Daniel Scherzer wrote:
> On Tue, Jun 17, 2025 at 4:26 PM Daniel Scherzer
> wrote:
>> Hi internals,
>>
>> I'd like to start the discussion for a new RFC about adding a
>> `#[\DelayedTargetValidation]` attribute.
>>
>> * RFC: https://wiki.php.net/rfc/delayedtarge
On Tue, Jun 17, 2025 at 4:26 PM Daniel Scherzer
wrote:
> Hi internals,
>
> I'd like to start the discussion for a new RFC about adding a
> `#[\DelayedTargetValidation]` attribute.
>
> * RFC: https://wiki.php.net/rfc/delayedtargetvalidation_attribute
> * Implementation: https://github.com/php/php-
On Sun, 15 Jun 2025, 9:12 pm Adam Cable, wrote:
> Hello internals,
>
> I'd like to present my first RFC - str_icontains, a case-insensitive
> friend of str_contains
>
> RFC: https://wiki.php.net/rfc/str_icontains
> PR (including tests): https://github.com/php/php-src/pull/18705
>
> Previous discu
On Tue, Jun 17, 2025 at 4:26 PM Daniel Scherzer
wrote:
> Hi internals,
>
> I'd like to start the discussion for a new RFC about adding a
> `#[\DelayedTargetValidation]` attribute.
>
> * RFC: https://wiki.php.net/rfc/delayedtargetvalidation_attribute
> * Implementation: https://github.com/php/php-
On Wed, Jun 18, 2025, at 10:59 AM, Volker Dusch wrote:
> On Wed, Jun 4, 2025 at 5:13 PM Volker Dusch wrote:
>> Hi everyone,
>> [...]
>> As with every RFC, a 2/3 majority is required.
>> Voting ends 2025-06-18 at 15:30:00 UTC.
>
> The voting has ended today.
>
> The clone-with-v2 RFC was accepted
On Wed, Jun 4, 2025 at 5:13 PM Volker Dusch
wrote:
> Hi everyone,
> [...]
> As with every RFC, a 2/3 majority is required.
> Voting ends 2025-06-18 at 15:30:00 UTC.
The voting has ended today.
The clone-with-v2 RFC was accepted with 16 (Yes) to 4 (No) votes (80% in
favor).
Tim will take care of
Hi Adam
On Fri, Jun 6, 2025 at 1:35 PM Adam Cable wrote:
>
> On Sat, May 31, 2025 at 11:22 AM Adam Cable wrote:
>>
>> Can I have RFC karma please for account adamcable please.
>
>
> Polite nudge :) Apologies if I've done this wrong.
Apologies, this slipped through the cracks. I granted you RFC
On Sat, May 31, 2025 at 11:22 AM Adam Cable wrote:
> Hi,
>
> Can I have RFC karma please for account adamcable please.
>
> I'm looking to create a RFC for str_icontains (and maybe more in the
> future).
>
> https://github.com/php/php-src/pull/18705
>
> Thanks,
> Adam
>
Polite nudge :) Apologies
Hi
Le mer. 4 juin 2025 à 15:33, Tim Düsterhus a écrit :
> Hi
>
> Am 2025-06-03 16:24, schrieb Nicolas Grekas:
> > - We decided to __clone before updating properties to avoid BC issues.
> >>
> >
> > Not sure which BC issues you've in mind, especially as that's a new
> > feature.
> > As I see it,
Hi
Am 2025-06-03 16:24, schrieb Nicolas Grekas:
- We decided to __clone before updating properties to avoid BC issues.
Not sure which BC issues you've in mind, especially as that's a new
feature.
As I see it, before or after wouldn't change anything as far as __clone
implementations are co
Hi Volker,
Sorry for the delay in answering, it's been a long week-end AFK on my side.
Le mer. 28 mai 2025 à 16:52, Volker Dusch a
écrit :
> Hi Nicolas,
>
> Thank you for the great email and for thinking this through. Getting input
> from the folks that maybe will use this feature the most is v
Hi everyone,
As there was no additional feedback for the last 5 days, and we feel the
RFC is in a good place, we intend to start voting on Wednesday if there are
no new concerns raised.
Thank you again!
Volker
On Mon, May 26, 2025 at 4:03 PM Volker Dusch
wrote:
> Version 1.1 Update: Array synt
On Wed, May 28, 2025 at 2:01 PM carlos_silva
wrote:
> Hello everyone.
>
> I've been thinking about core developers these days, and I'm happy to see
> the PHP foundation growing, and more and more new developers arriving,
> eager to push PHP forward.
>
> But at the same time, I have the feelin
Hello, Carlos!
Thank you for your support.
I feel like I should add a bit of jam to this story and share some news.
When I set the two-week limit for the vote, Roman Pronskiy reached out
to me almost immediately and offered direct contact with PHP CORE.
I received maximum support and valuable adv
Hello everyone.
I've been thinking about core developers these days, and I'm happy to see the
PHP foundation growing, and more and more new developers arriving, eager to
push PHP forward.
But at the same time, I have the feeling that some want to own it, are jealous,
or are simply arrogant.
T
Hi Nicolas,
Thank you for the great email and for thinking this through. Getting input
from the folks that maybe will use this feature the most is very valuable,
and I appreciate that you're taking the time to do this early.
On Mon, May 26, 2025 at 4:37 PM Nicolas Grekas
wrote:
> - To me, the m
On Mon, May 26, 2025 at 08:03 Volker Dusch wrote:
> Version 1.1 Update: Array syntax over named arguments.
>
> Thank you everyone for the discussion and for improving this RFC.
> I'm very happy with the updates we made thanks to your feedback on and off
> list.
>
> The main idea of this RFC wa
Hi
Clarifying on the technical questions.
Am 2025-05-26 16:37, schrieb Nicolas Grekas:
I think the RFC is missing a few bits to be complete:
- making "clone" a function means suddenly a "use clone;" or a "\clone"
is
going to be needed to not get a perf hit, isn't it? But since $y =
clone
$x
Hi Volker,
Thanks for the update.
Le lun. 26 mai 2025 à 16:05, Volker Dusch a
écrit :
> Version 1.1 Update: Array syntax over named arguments.
>
> Thank you everyone for the discussion and for improving this RFC. I'm very
> happy with the updates we made thanks to your feedback on and off list.
Version 1.1 Update: Array syntax over named arguments.
Thank you everyone for the discussion and for improving this RFC. I'm very
happy with the updates we made thanks to your feedback on and off list.
The main idea of this RFC was to have as little of a footprint as possible
and make it feel nat
On Wed, May 21, 2025 at 23:27 Larry Garfield wrote:
> On Wed, May 21, 2025, at 9:13 AM, Tim Düsterhus wrote:
>> Am 2025-05-19 12:48, schrieb Volker Dusch:
>>> We're still looking for feedback on the ...variadic approach to the
>>> Syntax:
>>> https://wiki.php.net/rfc/clone_with_v2#open_issues, as w
On Wed, May 21, 2025, at 9:13 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-05-19 12:48, schrieb Volker Dusch:
>> We're still looking for feedback on the ...variadic approach to the
>> Syntax:
>> https://wiki.php.net/rfc/clone_with_v2#open_issues, as we only got one
>> reply so far on the topic.
>
> I
Hi
Am 2025-05-21 17:27, schrieb Theodore Brown:
Combining named-parameter `array()` syntax with clone taking a array
as
the second parameter would allow for the following, which might
combine
the best of both worlds?
clone($obj, array(foo: 1, bar: "baz", object: "this is not
blocked"));
On Wed, May 21, 2025 at 09:13 Tim Düsterhus wrote:
> Am 2025-05-19 12:48, schrieb Volker Dusch:
>> We're still looking for feedback on the ...variadic approach to the
>> Syntax:
>> https://wiki.php.net/rfc/clone_with_v2#open_issues, as we only got one
>> reply so far on the topic.
>
> ...
>
> *So
Hi
Am 2025-05-21 16:27, schrieb Nicolas Grekas:
Thanks for sharing your insights. This looks a bit far reaching for the
RFC.
Making `array()` a function / allowing named parameter syntax with
`array()` would be a separate RFC.
On my side, my opinion is: don't make clone a function call. I'
Hi
Am 2025-05-19 12:48, schrieb Volker Dusch:
We're still looking for feedback on the ...variadic approach to the
Syntax:
https://wiki.php.net/rfc/clone_with_v2#open_issues, as we only got one
reply so far on the topic.
I was hoping for some additional opinions here before adding my own, but
Hi Tim,
Le mer. 21 mai 2025 à 16:15, Tim Düsterhus a écrit :
> Hi
>
> Am 2025-05-19 12:48, schrieb Volker Dusch:
> > We're still looking for feedback on the ...variadic approach to the
> > Syntax:
> > https://wiki.php.net/rfc/clone_with_v2#open_issues, as we only got one
> > reply so far on the
Hi
Am 2025-05-19 15:30, schrieb Larry Garfield:
For positional parameters, I don't see any way that they'd work or do
what someone expects. So why not just block them entirely instead of
relying on dynamic properties to warn-but-sorta-work?
For better or worse PHP supports numeric properties
On Mon, May 19, 2025, at 5:48 AM, Volker Dusch wrote:
> Hey everyone,
>
> Thank you for the participation so far, since the start of the
> discussion, from feedback on and off list, I've added a couple of
> examples:
>
> -
> https://wiki.php.net/rfc/clone_with_v2#:~:text=dynamic%20property%20cre
Hey everyone,
Thank you for the participation so far, since the start of the discussion,
from feedback on and off list, I've added a couple of examples:
-
https://wiki.php.net/rfc/clone_with_v2#:~:text=dynamic%20property%20creation%20follows%20established%20PHP%20rules
- https://wiki.php.net/rfc/
Hi,
Here is the announcement published by the PHP Foundation,
Les-Tilleuls.coop, and the Caddy team:
https://les-tilleuls.coop/en/blog/frankenphp-is-now-officially-supported-by-the-php-foundation
Best,
Hello, everyone.
While the code is being developed and changes for the RFC are in
progress, I’d like to share a real-world situation.
This is one of those cases that once again proves why software design
cannot happen without writing real code — why architecture is
impossible without practice.
`
Hi
Am 2025-05-07 19:15, schrieb Rowan Tommins [IMSoP]:
There are three "platform dependency" pseudo-packages available for
packages to depend on different aspects of Composer's version:
https://getcomposer.org/doc/articles/composer-platform-dependencies.md
If these didn't seem suitable, they c
On 07/05/2025 14:10, Tim Düsterhus wrote:
And rewrite all references inside of `Foo` to `Foo$Bar` (using Java's
name mangling). This is effectively what Ilija's proposal for
file-private classes did: https://externals.io/message/126331#126337.
I think this would also be nicer on the autoloading
On 07/05/2025 14:18, Tim Düsterhus wrote:
I don't think it is currently possible to define a minimum composer
version as part of a package’s dependencies.
There are three "platform dependency" pseudo-packages available for
packages to depend on different aspects of Composer's version:
https
On Mon, Mar 24, 2025 at 11:33 AM Daniel Scherzer <
daniel.e.scher...@gmail.com> wrote:
> Hi internals,
>
> I'd like to start the discussion for a new RFC about allowing final
> promoted properties. You can see some preliminary discussion at <
> https://externals.io/message/126475>, but this is now
Hi
Am 2025-05-06 21:33, schrieb Rowan Tommins [IMSoP]:
The classes that you'll need to be aware of will exist whether this
feature is added or not, and you'll already need to avoid conflicting
with them - usually by simply avoiding the main namespace prefix of the
library.
If this feature wa
Hi
Am 2025-05-06 22:04, schrieb Rob Landers:
I think these are fundamental problems (if they are a problem at all)
with how PHP currently does namespaces and names.
I don't think that this is a fundamental problem of namespaces and
names. Ilija solved the naming conflict issue in his file-pri
On 22/04/2025 22:52, Niels Dossche wrote:
> Hi internals
>
> I'm opening the vote for https://wiki.php.net/rfc/array_first_last
> Vote runs until 2025-05-06 23:59:59 CEST.
>
> Kind regards
> Niels
>
Hi internals
Vote ended with 35 yes, 0 no.
Thanks to all participants.
Merged into master.
Kin
On Mon, Apr 21, 2025 at 1:13 PM Daniel Scherzer
wrote:
> Hi internals,
>
> I have opened the vote on https://wiki.php.net/rfc/never-parameters-v2.
> The vote will run for 2 weeks (and a few hours), closing on May 5th at the
> end of the day (UTC).
>
> --Daniel
>
This RFC closed with a vote of 3-
On Sun, May 4, 2025, at 15:52, Tim Düsterhus wrote:
> Hi
>
> On 4/30/25 12:51, Rowan Tommins [IMSoP] wrote:
> > I think you are insisting on a different definition of "private" for nested
> > classes than exists anywhere else in the language, and one that I've not
> > seen evidence of in any oth
On 4 May 2025 14:52:23 BST, "Tim Düsterhus" wrote:
>> It's also not a new problem: PHP doesn't enforce a file and directory
>> layout, and libraries can and do define things "inside" each other's
>> namespaces. When declaring a class, you have to be aware of whether a class
>> with the same
Hi
On 4/30/25 12:51, Rowan Tommins [IMSoP] wrote:
I think you are insisting on a different definition of "private" for nested classes than
exists anywhere else in the language, and one that I've not seen evidence of in any other similar
language either. It seems you want members to be "hidden"
On Sun, 4 May 2025 at 14:57, Jochen Schultz wrote:
>
>
> Am 04.05.25, 13:07 schrieb Arvids Godjuks :
>>
>>
>>
>> On Sun, 4 May 2025 at 10:36, Michael Morris wrote:
>>
>>> It's been 9 months. Been researching, working on other projects, mulling
>>> over
>>> points raised the last time I brought t
On 29 April 2025 19:50:52 BST, "Tim Düsterhus" wrote:
>I'm saying that I cannot add a private class Foo\Bar inside of the class Foo
>without checking whether a class Bar inside a namespace Foo already exists,
>since both would conflict. Even more problematic: I can't add a class Bar
>inside
Hi
On 4/24/25 21:26, Rob Landers wrote:
This was very deliberate after much feedback and careful design. People were
quite clear (including yourself, if I recall) that they didn't want a new
syntax. Since there is no new syntax, there is no way to tell (from the
outside) whether A\B\C refers
On Thu, Apr 24, 2025, at 17:20, Tim Düsterhus wrote:
> Hi
>
> On 4/24/25 17:09, Rob Landers wrote:
> > Thank you for your feedback! I think you would then have the problem that
> > was pointed out by Levi the other day; where you would then have ambiguity.
> > If you could have both private an
Hi
On 4/20/25 15:43, Rob Landers wrote:
As it seems that discussion has mostly died down, I'd like to put this towards
a vote starting on May 1, 2025.
Unfortunately I did not have the time to follow the discussion after
mid-March, so this might or might not have been discussed already. I
ju
Hi
On 4/24/25 17:09, Rob Landers wrote:
Thank you for your feedback! I think you would then have the problem that was
pointed out by Levi the other day; where you would then have ambiguity. If you
could have both private and public names in the same namespace, then you would
end up not knowin
On Thu, Apr 24, 2025, at 16:31, Tim Düsterhus wrote:
> Hi
>
> On 4/20/25 15:43, Rob Landers wrote:
> > As it seems that discussion has mostly died down, I'd like to put this
> > towards a vote starting on May 1, 2025.
>
> Unfortunately I did not have the time to follow the discussion after
>
On Sun, Apr 20, 2025 at 9:30 AM Niels Dossche wrote:
>
> On 05/04/2025 17:51, Niels Dossche wrote:
> > Hi internals
> >
> > I'm opening the discussion for the RFC "array_first() and array_last()".
> > https://wiki.php.net/rfc/array_first_last
> >
> > Kind regards
> > Niels
> >
>
>
> Hi
>
> I'll be
For Recommending to people please read the manuals + guides:~
extract Sentential Entity 6.5 AMD64 Manuals as Tiesaa Binders
extract Sentential Entity 6.5 AMD64 Guides as Tiesaa Binders
extract Sentential Entity 6.5 ARM64 Manuals as Tiesaa Binders
extract Sentential Entity 6.5 ARM64 Guides as Tiesa
On Tue, Apr 22, 2025, at 19:22, Levi Morrison wrote:
> On Sun, Apr 20, 2025 at 7:46 AM Rob Landers wrote:
> >
> > On Mon, Mar 31, 2025, at 21:45, Rob Landers wrote:
> >
> > Hello internals,
> >
> > I have significantly revamped the RFC (again). Key changes to the RFC:
> >
> > 1. More (realistic)
On Sun, Apr 20, 2025 at 7:46 AM Rob Landers wrote:
>
> On Mon, Mar 31, 2025, at 21:45, Rob Landers wrote:
>
> Hello internals,
>
> I have significantly revamped the RFC (again). Key changes to the RFC:
>
> 1. More (realistic) examples,
> 2. Since enums are basically specialized classes, they are a
1 - 100 of 13233 matches
Mail list logo
