On Wed, Jun 4, 2025 at 6:41 PM Larry Garfield <la...@garfieldtech.com> wrote:
> While I support this RFC and want to see it in, I have voted no for 2 > reasons. > > 1. The switch to an array parameter, as previously noted, is a major DX > loss for unclear benefit. It's just all-around a worse design, and "maybe > we can change how arrays work in the future" is not an answer. > It is frustrating that you claim the benefits to be unclear after multiple long explanations, when this was thankfully unearthed during RFC discussion. Inventing a new syntax for this specific function call is something, I couldn't go forward with this, and I think we explained well why in the thread. But to sum up again for the benefits of readers: Using a ...variadic to generate a key-value array is something php-src doesn't do *anywhere* currently, and it has multiple issues and edge cases. It is making the language more inconsistent and harder to use. Adding this special syntax for a single function is unacceptable to me. While it looks nicer to people who don't use or like PHP arrays much, an array is PHP's, especially php-src's, main way of passing a list of key-value pairs. While vibes-based language design is tempting, and I've fallen for it initially in this RFC. I want to work with the reality of how PHP works here and not leave all problems coming from this to the core team. The alternative syntax would introduce extra documentation effort, inconsistency in how PHP core functions work, and generate bug reports stemming from the edge cases outlined. I'd rather not have the feature at all than burden maintainers with this. Especially given how negligible the difference is in typing effort is in the end, and how it doesn't change static analysis or IDE support. But I know we disagree on that point. This RFC is also leaving room for future improvement by still allowing to add further parameters if the unforeseen need for this should come up. Ideas around changing PHPs syntax for key-value pair lists shouldn't have been attached to this in the first place. Extracting the ideas from this discussion into things like `#[NamedParameterOnly]`, a potential 3rd array syntax `[foo: "bar"]` people argued for, or ideas like this https://github.com/php/php-src/pull/18613 . But none of this has a place in clone-with as introducing a new way of defining an array here instead of somewhere generic isn't something I feel helps PHP. > 2. There was still an active discussion with Nicolas going on that seemed > rather important. Opening the vote while that was still going on is, as > noted above, problematic. > > --Larry Garfield > We answered the concerns multiple times in the discussion, including declaring it out of scope in the initial RFC text and explaining the issues with adding parameters to __clone in the discussions. This RFC also leaves these, very much out of scope for this RFC, open in the future. They would massively increase the scope of this and require a ton of discussion that killed the first attempt at incremental improvement already. So from my perspective, there was no active discussion going on as nobody else spoke up for a week and nothing changed with Nicolas, admittedly regrettably timed, last email. Which we also answered in detail. So I fail to see how this problematic. Letting the RFC peter out and die in the discussion, like so many others, is not a desired outcome for me and as this implementation doesn't block any future improvements or make anything worse in userland. Regards, Volker -- Volker Dusch Head of Engineering Tideways GmbH Königswinterer Str. 116 53227 Bonn https://tideways.io/imprint Sitz der Gesellschaft: Bonn Geschäftsführer: Benjamin Außenhofer (geb. Eberlei) Registergericht: Amtsgericht Bonn, HRB 22127
