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; is still going to be valid, how will this be handled? The RFC could
give some more hints on the topic.
The implementation of making clone a function matches that of making exit() a function in PHP 8.4 (https://wiki.php.net/rfc/exit-as-function). Specifically, clone will remain a keyword and any use of a bare clone will compile to a fully-qualified call to the clone function, as if you would have written \clone(). For the same reason it will remain impossible to define a clone() function within a namespace. It will also be disallowed to use disable_functions=clone (the same as with exit and die).
That clone() will become a function should be considered an implementation detail. You might start seeing a clone() frame in your stack traces, within assert(false && clone($foo)) the \clone() call will be fully-qualified in the error message output and error messages might slightly change (e.g. when passing a non-object to clone). Other than that, it should not be noticeable. Perhaps even the ZEND_CLONE opcode will remain when using clone with a single-parameter (this is similarly to the other optimization of “special functions”, such as count() or sprintf()).
I have made the following changes to the RFC that should hopefully clarify things: https://wiki.php.net/rfc/clone_with_v2?do=diff&rev2%5B0%5D=1748270099&rev2%5B1%5D=1748272162&difftype=sidebyside
- 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.
Only use function clone; is currently invalid syntax (and it will remain invalid syntax, similarly to use function exit;). clone($a) currently is a perfectly valid cloning statement (with redundant parentheses) and \clone($a) is a valid call to a function called clone that does not exist: https://3v4l.org/VB3j1
But as I said above, it is not necessary to change any existing code. The RFC is clear on that: There are no backwards incompatible changes regarding the usage. When finalizing the implementation, I'll make sure to run some benchmarks to determine whether or not keeping the OPcode is worth it for the “non-with” case, or whether making clone a “frameless” function would bring any benefit. But making sure it runs fast is the job of the engine, not the job of the PHP developer and generally speaking performance characteristics can change even without RFCs.
It could make sense to tell about this and show an example like this one in
the RFC.
Given that your question appears to be based on a misunderstanding, I believe adding such an example to the RFC is not useful.
- 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.
As the RFC specifies, clone-with behaves exactly like regular property assignments. This means your example behaves like `$foo->{"\0Foo\0bar"} = 123;` and thus will throw “Error: Cannot access property starting with "\0"”. I have added a test to the implementation [1]. Adding that to the RFC text itself is probably not useful to the average reader, since this is not something they will encounter.
Best regards
Tim Düsterhus
[1] https://github.com/TimWolla/php-src/pull/6/commits/6f55e142e55af013bed0f31d7dc1633ef8201bff