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

Hi, > I think the initial idea is good, but ultimately its usefulness seems > too limited to me as well, and methods such as the one Nicolas > mentions with “0 + $var” seem sufficient. I'm sorry, this is the wrong thread. Here is the RFC being withdrawn: https://wiki.php.net/rfc/is-representable-

[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

[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: >

[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:

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

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

[PHP-DEV] Re: RFC karma request

I forgot to specify my username. Sorry. Haha It's cviniciussdias Thank you.

Re: [PHP-DEV] Re: [RFC] Add "is_representable_as_float()" and "is_representable_as_int()" functions

> 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

Re: [PHP-DEV] Re: [RFC] Add "is_representable_as_float()" and "is_representable_as_int()" functions

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

[PHP-DEV] Re: [RFC] Add "is_representable_as_float()" and "is_representable_as_int()" functions

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

[PHP-DEV] Re: [RFC] Add "is_representable_as_float()" and "is_representable_as_int()" functions

> 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

[PHP-DEV] Re: [RFC] [Discussion] FILTER_THROW_ON_FAILURE

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

[PHP-DEV] Re: [RFC] [Discussion] #[\Deprecated] for traits

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

[PHP-DEV] Re: [RFC] JSON Schema validation support

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

[PHP-DEV] Re: [RFC] Drop support for 32bit builds

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.

Re: [PHP-DEV] Re: [RFC] Readonly property hooks

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

Re: [PHP-DEV] Re: [RFC] Readonly property hooks

> 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

Re: [PHP-DEV] Re: [RFC] Readonly property hooks

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

Re: [PHP-DEV] Re: [RFC] Readonly property hooks

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

Re: [PHP-DEV] Re: [RFC] Readonly property hooks

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

Re: [PHP-DEV] Re: [RFC] Readonly property hooks

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

Re: [PHP-DEV] Re: [RFC] Readonly property hooks

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

[PHP-DEV] Re: [RFC] Readonly property hooks

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

[PHP-DEV] Re: [RFC] [Discussion] #[\DelayedTargetValidation] attribute

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-

[PHP-DEV] Re: [RFC idea] Target-aware attributes

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

Re: [PHP-DEV] Re: [RFC] [Discussion] #[\DelayedTargetValidation] attribute

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

Re: [PHP-DEV] Re: [RFC] [Discussion] #[\DelayedTargetValidation] attribute

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

Re: [PHP-DEV] Re: [RFC] [Discussion] #[\DelayedTargetValidation] attribute

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

Re: [PHP-DEV] Re: [RFC] [Discussion] #[\DelayedTargetValidation] attribute

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

Re: [PHP-DEV] Re: [RFC] [Discussion] #[\DelayedTargetValidation] attribute

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

[PHP-DEV] Re: [RFC] [Discussion] #[\DelayedTargetValidation] attribute

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-

[PHP-DEV] Re: [RFC] str_icontains

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

[PHP-DEV] Re: [RFC] [Discussion] #[\DelayedTargetValidation] attribute

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-

Re: [PHP-DEV] Re: RFC karma

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

[PHP-DEV] Re: RFC karma

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

Re: [PHP-DEV] Re: [RFC] Clone with v2

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,

Re: [PHP-DEV] Re: [RFC] Clone with v2

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

Re: [PHP-DEV] Re: [RFC] Clone with v2

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

[PHP-DEV] Re: [RFC] Clone with v2

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

Re: [PHP-DEV] Re: [RFC] Clone with v2

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

Re: [PHP-DEV] Re: [RFC] Clone with v2

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

Re: [PHP-DEV] Re: [RFC] Clone with v2

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

Re: [PHP-DEV] Re: [RFC] Clone with v2

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.

[PHP-DEV] Re: [RFC] Clone with v2

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

Re: [PHP-DEV] Re: [RFC] Clone with v2

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

Re: [PHP-DEV] Re: [RFC] Clone with v2

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

Re: [PHP-DEV] Re: [RFC] Clone with v2

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"));

Re: [PHP-DEV] Re: [RFC] Clone with v2

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

Re: [PHP-DEV] Re: [RFC] Clone with v2

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'

Re: [PHP-DEV] Re: [RFC] Clone with v2

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

Re: [PHP-DEV] Re: [RFC] Clone with v2

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

Re: [PHP-DEV] Re: [RFC] Clone with v2

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

Re: [PHP-DEV] Re: [RFC] Clone with v2

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

[PHP-DEV] Re: [RFC] Clone with v2

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/

Re: [PHP-DEV] Re: RFC: Nested Classes

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

Re: [PHP-DEV] Re: RFC: Nested Classes

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

Re: [PHP-DEV] Re: RFC: Nested Classes

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

[PHP-DEV] Re: [RFC] [Discussion] Final promoted properties

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

Re: [PHP-DEV] Re: RFC: Nested Classes

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

Re: [PHP-DEV] Re: RFC: Nested Classes

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

[PHP-DEV] Re: [RFC] [Vote] array_first() and array_last()

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

Re: [PHP-DEV] Re: RFC: Nested Classes

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

Re: [PHP-DEV] Re: RFC: Nested Classes

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

Re: [PHP-DEV] Re: RFC: Nested Classes

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"

Re: [PHP-DEV] Re: RFC: Nested Classes

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

Re: [PHP-DEV] Re: RFC: Nested Classes

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

Re: [PHP-DEV] Re: RFC: Nested Classes

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

Re: [PHP-DEV] Re: RFC: Nested Classes

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

Re: [PHP-DEV] Re: RFC: Nested Classes

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

Re: [PHP-DEV] Re: RFC: Nested Classes

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 >

Re: [PHP-DEV] Re: [RFC] [Discussion] array_first() and array_last()

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

Re: [PHP-DEV] Re: RFC: Nested Classes (was: short and inner classes)

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)

Re: [PHP-DEV] Re: RFC: Nested Classes (was: short and inner classes)

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

Re: [PHP-DEV] Re: [RFC] [Discussion] array_first() and array_last()

On 22/04/2025 18:51, Levi Morrison wrote: > I don't think it blocks this RFC in any way, and could be made > frameless after the vote--I just wanted to bring up that I think > they _should_ be frameless if they get accepted (and update > array_key_first/array_key_last to be frameless too). Hi Ind

[PHP-DEV] Re: [RFC] [Discussion] array_first() and array_last()

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 putting this to vote on Tuesday 22nd if no one has complaints. Kind regards

[PHP-DEV] Re: RFC: Nested Classes (was: short and inner classes)

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 allowed to be > nested as well (hat tip to Reddit), > 3.

Re: [PHP-DEV] Re: [RFC] [Discussion] Never parameters

On Tue, 15 Apr 2025 at 20:59, Daniel Scherzer wrote: > > On Tue, Apr 8, 2025 at 6:40 PM Daniel Scherzer > wrote: >> >> >> Since a lot of the discussion seems to be around static analysis and whether >> there is a real use case for this, I wanted to share another use case I just >> came across:

[PHP-DEV] Re: [RFC] [Discussion] Never parameters

On Tue, Apr 8, 2025 at 6:40 PM Daniel Scherzer wrote: > > Since a lot of the discussion seems to be around static analysis and > whether there is a real use case for this, I wanted to share another use > case I just came across: in the `thephpleague/commonmark` package, > different renderers are

[PHP-DEV] Re: [RFC] [Discussion] Never parameters

On Mon, Mar 10, 2025 at 12:05 PM Daniel Scherzer < daniel.e.scher...@gmail.com> wrote: > Hi internals, > > I'd like to start discussion on a new RFC about allowing `never` for > parameter types when declaring a method. > > * RFC: https://wiki.php.net/rfc/never-parameters-v2 > * Implementation: htt

Re: [PHP-DEV] Re: RFC: short and inner classes

On 24 March 2025 09:20:03 GMT, "Alexandru Pătrănescu" wrote: >On Sun, Mar 23, 2025 at 5:20 PM Larry Garfield >wrote: > >> >> So, how would nested classes compare to fileprivate, in terms of ability >> to solve the problem space? As I understand it, the goal is: >> >> 1. Classes that can be i

Re: [PHP-DEV] Re: RFC: short and inner classes

On Sun, Mar 23, 2025 at 5:20 PM Larry Garfield wrote: > > So, how would nested classes compare to fileprivate, in terms of ability > to solve the problem space? As I understand it, the goal is: > > 1. Classes that can be instantiated only by the class that uses them. > 2. But can be returned fro

Re: [PHP-DEV] Re: RFC: short and inner classes

On Wed, Mar 12, 2025, at 5:10 AM, Rob Landers wrote: > Hello internals, > > I've made some major updates to the text of the RFC to clarify > behaviors and revisited the implementation (which is still under > development, though I hope to have a draft by the end of this weekend). > Here's a broa

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Am 2025-03-14 01:22, schrieb Bob Weinand: […] class constants in uppercase […] enum cases are a notable Exception. They also use PascalCase (both internal enums and the PER-CS coding style as published by PHP-FIG). But that's also a good question for the RFC author: Is defining inner cl

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Am 2025-03-13 21:46, schrieb Rob Landers: I will give \\ a try, but it has to be typed quite a bit when referencing inner classes, so keeping it easy to type is a must. I feel like \\ requires a large movement to type, at least on a qwerty non-english keyboard. Maybe people using other keyb

Re: [PHP-DEV] Re: RFC: short and inner classes

On Wed, Mar 12, 2025, at 11:10, Rob Landers wrote: > On Thu, Mar 6, 2025, at 00:11, Rob Landers wrote: >> Hello PHP Internals, >> >> I'd like to introduce my RFC for discussion: >> https://wiki.php.net/rfc/short-and-inner-classes >> >> This RFC defines a short class syntax as well as the ability

Re: [PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 13, 2025, at 23:26, Bob Weinand wrote: > Hey Rob, > > On 13.3.2025 21:46:49, Rob Landers wrote: >> On Thu, Mar 13, 2025, at 12:01, Tim Düsterhus wrote: >>> Hi >>> >>> Am 2025-03-12 11:10, schrieb Rob Landers: >>> > - Accessing inner classes is done via a new token: ":>" instead of

Re: [PHP-DEV] Re: RFC: short and inner classes

Hey Rob, On 14.3.2025 00:26:03, Rob Landers wrote: My biggest issue with `::` is that it gets weird: class Foo {   public class Bar {}   public const Bar = "";   public static function Bar() {} } echo Foo::Bar; // this is the constant new Foo::Bar(); // this is the class Foo::Bar(); // this is

Re: [PHP-DEV] Re: RFC: short and inner classes

Hey Rob, On 13.3.2025 21:46:49, Rob Landers wrote: On Thu, Mar 13, 2025, at 12:01, Tim Düsterhus wrote: Hi Am 2025-03-12 11:10, schrieb Rob Landers: > - Accessing inner classes is done via a new token: ":>" instead of > "::". I don't particularly like that. It is “invented syntax” and I don't

Re: [PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 13, 2025, at 21:41, Ilija Tovilo wrote: > Hi Rob > > On Thu, Mar 13, 2025 at 1:57 PM Rob Landers wrote: > > > > > the proposal is > > > currently quite complex. > > > > Most of this is just describing how classes work already and going in-depth > > on where there may be confusion --

Re: [PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 13, 2025, at 12:01, Tim Düsterhus wrote: > Hi > > Am 2025-03-12 11:10, schrieb Rob Landers: > > - Accessing inner classes is done via a new token: ":>" instead of > > "::". > > I don't particularly like that. It is “invented syntax” and I don't > think that inner classes are suffi

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Rob On Thu, Mar 13, 2025 at 1:57 PM Rob Landers wrote: > > > the proposal is > > currently quite complex. > > Most of this is just describing how classes work already and going in-depth > on where there may be confusion -- there are no significant changes to how > classes actually work. The

Re: [PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 13, 2025, at 12:41, Ilija Tovilo wrote: > Hi Rob > > On Thu, Mar 13, 2025 at 12:01 PM Tim Düsterhus wrote: > > > > Am 2025-03-12 11:10, schrieb Rob Landers: > > > - Accessing inner classes is done via a new token: ":>" instead of > > > "::". > > > > I don't particularly like that. It

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Rob On Thu, Mar 13, 2025 at 12:01 PM Tim Düsterhus wrote: > > Am 2025-03-12 11:10, schrieb Rob Landers: > > - Accessing inner classes is done via a new token: ":>" instead of > > "::". > > I don't particularly like that. It is “invented syntax” and I don't > think that inner classes are suffic

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Am 2025-03-12 11:10, schrieb Rob Landers: - Accessing inner classes is done via a new token: ":>" instead of "::". I don't particularly like that. It is “invented syntax” and I don't think that inner classes are sufficiently valuable to dedicate an entire operator to them that could serve

[PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 6, 2025, at 00:11, Rob Landers wrote: > Hello PHP Internals, > > I'd like to introduce my RFC for discussion: > https://wiki.php.net/rfc/short-and-inner-classes > > This RFC defines a short class syntax as well as the ability to nest classes > inside another class. This introduces a

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On Tue, Mar 4, 2025, 23:22 Tim Düsterhus wrote: > > > Or identify that the function has the NoDiscard attribute and based on > that > > do not optimize away the variable? > > First things first: It's not a super important optimization to have, the > assignment to a variable is one of the cheaper

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

Hi On 3/4/25 23:08, Alexandru Pătrănescu wrote: Just asking, as my engine knowledge is a bit limited, Wouldn't it be possible that when OPcache would optimize away the unused variable assigned to a function, it could detect that that function have the NoDiscard attribute and also remove the attr

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

Hi Tim, On Tue, Mar 4, 2025, 22:16 Tim Düsterhus wrote: > Hi Marc > > Should the `(void)` cast not be accepted, we will only special case the > assignment to `$_` to not be elided, even if OPcache knows that the > function will never return an object. The behavior for other variables > will rema

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

Hi Marc On 3/3/25 17:14, Marc B. wrote: In this thread, I only found the information that currently OPcache does not discard such unused assignments. It would be good to know if such optimization could be considered to not end up in a situation that such optimization would be useful but can't be

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

Hi,Am 03.03.2025 15:30 schrieb Volker Dusch :On Wed, Jan 29, 2025 at 4:12 PM Tim Düsterhus wrote:Volker and I would like to start discussion on our RFC to allow "Markingreturn values as important (#[\NoDiscard])".Please find the following resources for your reference:- RFC: http

[PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On Wed, Jan 29, 2025 at 4:12 PM Tim Düsterhus wrote: > Volker and I would like to start discussion on our RFC to allow "Marking > return values as important (#[\NoDiscard])". > > Please find the following resources for your reference: > > - RFC: https://wiki.php.net/rfc/marking_return_value_as_im

  1   2   3   4   5   6   7   8   9   10   >