[RFC] Clone with v2

A magic __clone() method will be called before the new properties are assigned.
Why before and not after? I could probably make a good argument either direction, but we should be explicit about why we're making whatever decision.

From a user-facing perspective, calling __clone() before makes it easy
to know which state the object is in; all parameters are how they've
been before the clone operation started and are therefore consistent.
When calling __clone() afterward access to the new properties would
already be set and the old ones gone, making this potentially harder to
work with and harder to adapt existing implementations. So we chose the
one that causes fewer potential issues and gotchas.

Please include this in the RFC.

Let me just reiterate here that I find the difference to be minor to
negligible. IDE/Tooling support needs to be built explicitly either way
and is not harder or easier to do, and the ergonomics are quite
unaffected in my opinion. So the worst outcome, for me, would be that
we get hung up on the syntax here.

I think the current syntax is optimal.

One shouldn't be using a named argument for that anyway.

I'm not sure what you mean by that. Just so we're clear:
...["__object" => "foo"] would also not work with the current
implementation, as that's the same thing as a __object: $value named
argument. (Should we decide to name the first parameter __object here).
Sorry if I'm misunderstanding.

The concern is someone calling clone($foo, object: new Thingie()), which would complain that "object" is defined twice. Making the first argument named __object sidesteps that issue.

If someone then calls clone(prop: 'new val', __object: $foo), that... I suppose would technically compile, but one should never do that, and I am perfectly happy if that breaks. Similar for if someone called clone(prop: 'new val', object: $foo) if we didn't rename that parameter. No one should be doing that and I am fine if that breaks.

--Larry Garfield

The internal implementation is roughly equivalent to:

 $cloned = clone $object;
 foreach ($withProperties as $key => $value) {
     $cloned->{$key} = $value;
 }
 return $cloned;

Just with the exception that writing readonly properties is allowed on
the clone (unless already touched by __clone()).

Subtle point here. If the __clone() method touches a readonly property, does that make the property inaccessible to the new clone-with? Or is it a separate "unlock scope"? I would expect the latter. A single unlock block would be confusing to me.

--Larry Garfield

The only question that arose for me is: what happens if a property name is provided to clone() that does not exist in the class definition; what will be the behavior at that time? Will an exception or error be thrown? If so, will it be a new one, or an existing one?

Thank you for the question. I had that one myself looking at the initial implementation and forgot to write that down more explicitly.

Tim already answered and linked the test, but I've also added an example to the RFC.

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

I may be missing something here..

So far the issues are "how do we deal with a parameter for the actual object, vs new properties to apply", "should __clone be called before or after the changes" and "this won't allow regular readonly properties to be modified".

Isn't the previous suggestion of passing the new property arguments directly to the __clone method the obvious solution to all three problems?

There's no potential for a conflicting property name, the developer can use the new property values in the order they see fit relative to the logic in the __clone call, and it's inherently in scope to write to any (unlocked during __clone) readonly properties.

Cheers

Stephen

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 in objects and it
does not seem correct to make this an artificial limitation when the
behavior of numeric array keys follows the existing semantics (e.g. when
casting an array to an object).

Best regards
Tim Düsterhus

Hi Tim,

Le mer. 21 mai 2025 à 16:15, Tim Düsterhus tim@bastelstu.be 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 topic.

I was hoping for some additional opinions here before adding my own, but
since this does not appear to happen, adding my personal opinion on this
matter now:

Some property name being completely incompatible with “clone with” (no
matter how the first parameter is going to be called) is a limitation
that should not exist, it feels like a feature that is broken by design
and I think I really would hate it if the documentation of this RFC
would need a “Caution: It is not possible to reassign a property called
'$object', due to a parameter name conflict”.

Adjusting the signature to clone(object $object, array $withProperties) would not have this problem and I don't consider the
additional verbosity of an array literal to be a problem. Static
analysis tools already understand array shapes and would need
adjustments either way to understand the semantics.

From an implementation PoV a regular array parameter would also be
simpler, since the implementation would be able to simply pass along the
input array, whereas the “variadic” syntax needs special handling to
combine positional parameters with named parameters into a single array
that is then used in the cloning process.

Syntax-wise there might also be a middle-ground. Similarly to how this
RFC turns clone() into a function, the array() syntax also looks
like a function call and would naturally extend to named parameters.
While mixing positional and named parameters would probably get complex,
allowing purely named parameters would trivially be possible (without
any function call overhead). It would also allow using the
first-class-callable syntax with array(...), something I would liked
to have in the past. A proof of concept PR is at:

https://github.com/php/php-src/pull/18613

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

Thanks for sharing your insights. This looks a bit far reaching for the RFC.

On my side, my opinion is: don't make clone a function call. I've never
missed not being able to call clone as a callback. It's trivial to write a
short function using the operator when in need.

Nicolas

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.

...

Some property name being completely incompatible with “clone with” (no
matter how the first parameter is going to be called) is a limitation
that should not exist, it feels like a feature that is broken by design
and I think I really would hate it if the documentation of this RFC
would need a “Caution: It is not possible to reassign a property called
'$object', due to a parameter name conflict”.

Adjusting the signature to clone(object $object, array $withProperties)
would not have this problem and I don't consider the additional verbosity
of an array literal to be a problem. Static analysis tools already
understand array shapes and would need adjustments either way to
understand the semantics.

From an implementation PoV a regular array parameter would also be
simpler, since the implementation would be able to simply pass along the
input array, whereas the “variadic” syntax needs special handling to
combine positional parameters with named parameters into a single array
that is then used in the cloning process.

The more I've thought about it, the more I also don't like the variadic
approach. It seems like a hack to try to get property: value syntax
for "free", but at a fundamental level the API doesn't make sense for
its purpose.

Not only does it prevent setting a property with the name of the first
parameter (with no workaround), but it also means that someone could
call the function with positional rather than named arguments, which
as the RFC admits "for clone this is usually not useful".

Even if it's slightly less ergonomic to quote property names in array keys,
I agree with Tim that it would be better to change the function signature to:

function clone(object $object, array $withProperties): object {}

This simply removes the issue of not being able to set a certain property
name, as well as the confusing positional parameter behavior.

Syntax-wise there might also be a middle-ground. Similarly to how this
RFC turns clone() into a function, the array() syntax also looks
like a function call and would naturally extend to named parameters.
While mixing positional and named parameters would probably get complex,
allowing purely named parameters would trivially be possible (without
any function call overhead). It would also allow using the
first-class-callable syntax with array(...), something I would liked
to have in the past. A proof of concept PR is at:

https://github.com/php/php-src/pull/18613

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

I really like this idea! If it can work without any function call overhead,
it would enable more ergonomic array creation not only for clone() but
also in many other common scenarios.

Regards,
Theodore

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
since this does not appear to happen, adding my personal opinion on this
matter now:

Some property name being completely incompatible with “clone with” (no
matter how the first parameter is going to be called) is a limitation
that should not exist, it feels like a feature that is broken by design
and I think I really would hate it if the documentation of this RFC
would need a “Caution: It is not possible to reassign a property called
'$object', due to a parameter name conflict”.

I completely disagree here. The __ prefix is sufficient to solve the issue. A double underscore prefix has been understood to mean "internal to PHP, magic here" for at least 20 years. The chances of someone having a property called $__object are virtually nil, and if they do, they're already treading on naming that's reserved for PHP's use anyway so if it breaks, it's their own fault.

Adjusting the signature to clone(object $object, array $withProperties) would not have this problem and I don't consider the
additional verbosity of an array literal to be a problem. Static
analysis tools already understand array shapes and would need
adjustments either way to understand the semantics.

From an implementation PoV a regular array parameter would also be
simpler, since the implementation would be able to simply pass along the
input array, whereas the “variadic” syntax needs special handling to
combine positional parameters with named parameters into a single array
that is then used in the cloning process.

Syntax-wise there might also be a middle-ground. Similarly to how this
RFC turns clone() into a function, the array() syntax also looks
like a function call and would naturally extend to named parameters.
While mixing positional and named parameters would probably get complex,
allowing purely named parameters would trivially be possible (without
any function call overhead). It would also allow using the
first-class-callable syntax with array(...), something I would liked
to have in the past. A proof of concept PR is at:

https://github.com/php/php-src/pull/18613

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

I completely disagree here as well. I actively dislike using an array here, as I do find quoting all the keys to be cumbersome. And I don't think we should go with a worse syntax in the hopes of it being improved later, when there may well be other unforeseen challenges there. (Eg, I have no idea if bare array keys would cause issues with constants.) Moreover, we have 15 years of training and coding standards and automation tools that say to never use array(), always []. Reversing that would be far more disruptive for the ecosystem, even if it turns out to be not too disruptive to the code.

I strongly prefer the current syntax, and if the RFC changed to require an array I would strongly consider voting No on those grounds alone.

--Larry Garfield

Hi Volker,

Thanks for the update.

Le lun. 26 mai 2025 à 16:05, Volker Dusch volker@tideways-gmbh.com 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.

The main idea of this RFC was to have as little of a footprint as possible
and make it feel natural in PHP. I got carried away a bit during writing
this, and by using named arguments, introduced something that isn't used in
php-src provided functions, had edge cases that required documentation, and
all in all, didn't feel natural in PHP but like an inconsistency. PHP uses
arrays to pass lists everywhere else, so changing this here feels like too
much scope for this little change. I'm very happy this was caught and
raised in the discussions. Thank you.

If there is desire for named-parameter-as-an-array syntax this should be
standalone RFC with more scope than a single function.

We've updated the RFC and the implementation, removing the "Open Issue"
listed before, as this change resolved all of them.

• https://wiki.php.net/rfc/clone_with_v2
• https://github.com/TimWolla/php-src/pull/6

To me, it would have made more sense to still make "clone" an operator but
I think we can all get used to the array style, so if the majority thinks
arrays should be the way to go, so be it.

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; is still going to be valid, how will this be handled? The RFC could
  give some more hints on the topic.

• writing code with a wide range of supported PHP versions means we'll
  start using construct such as:
  if (PHP_VERSION_ID>=80500) {
  $b = 'clone'($a, [...]); // note 'clone' is a string here, so that the
  line is valid syntax on PHP <= 8.4
  else {
  // another code path for PHP 8.4
  }
  That's of course because "use clone", "\clone" or "clone($foo)" is invalid
  PHP syntax currently.
  It could make sense to tell about this and show an example like this one in
  the RFC.

• what if one gives a mangled property in the array? clone($foo,
  ["\0Foo\0bar" => 123])
  It could be useful to write something about this case and/or at least have
  a test case that shows how this should behave.

• To me, the main technical drawback of the RFC is that it builds on
  mandatory deep-cloning, which means wasted CPU/mem resources by design.
  This has to be mentioned in the RFC IMHO so that voters can make an
  informed decision.

About this last point, it's the one that makes me undecided about my voting
decision on the RFC.
I shared my concern and a solution in another thread, where I also address
the BC concern that is mentioned in the RFC. Since this concern has been
addressed, I think this should be considered more closely. As is, that's a
big omission to me - recognizing and addressing the issue with deep-cloning.

Cheers,
Nicolas

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 natural in PHP. I got carried away a bit during writing this, and
by using named arguments, introduced something that isn't used in php-src
provided functions, had edge cases that required documentation, and all in all,
didn't feel natural in PHP but like an inconsistency. PHP uses arrays to pass
lists everywhere else, so changing this here feels like too much scope for this
little change. I'm very happy this was caught and raised in the discussions.
Thank you.

If there is desire for named-parameter-as-an-array syntax this should be
standalone RFC with more scope than a single function.

We've updated the RFC and the implementation, removing the "Open Issue" listed
before, as this change resolved all of them.

• https://wiki.php.net/rfc/clone_with_v2
• https://github.com/TimWolla/php-src/pull/6

Thank you Volker and Tim for your work on this RFC. It will be a great quality-
of-life improvement for the language, and I look forward to voting in favor.

Theodore

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 volker@tideways-gmbh.com
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 was to have as little of a footprint as possible
and make it feel natural in PHP. I got carried away a bit during writing
this, and by using named arguments, introduced something that isn't used in
php-src provided functions, had edge cases that required documentation, and
all in all, didn't feel natural in PHP but like an inconsistency. PHP uses
arrays to pass lists everywhere else, so changing this here feels like too
much scope for this little change. I'm very happy this was caught and
raised in the discussions. Thank you.

If there is desire for named-parameter-as-an-array syntax this should be
standalone RFC with more scope than a single function.

We've updated the RFC and the implementation, removing the "Open Issue"
listed before, as this change resolved all of them.

• https://wiki.php.net/rfc/clone_with_v2
• https://github.com/TimWolla/php-src/pull/6

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

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