Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127463
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 26 May 2025 17:10:53 +0200
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: Volker Dusch <volker@tideways-gmbh.com>, php internals
 <internals@lists.php.net>
Subject: Re: [PHP-DEV] Re: [RFC] Clone with v2
In-Reply-To: <CAOWwgpkO8VasKSP5QMC0kwN58OihdTc+JeQ_s_XsNnJBZz9E7w@mail.gmail.com>
References: <CAMzRQTdePFXUMWO38g=gQA2vbqL5zp=o1cPt00ec41g95xys=g@mail.gmail.com>
 <CAMzRQTe_vn1a-ji9M2NXnBgJm3eHOGTHozWpM1jGzOht_sNs4w@mail.gmail.com>
 <CAMzRQTe-moWS4acwUHesA=K_pb+z+J8H_aMHCesyZL3qjG7z-g@mail.gmail.com>
 <CAOWwgpkO8VasKSP5QMC0kwN58OihdTc+JeQ_s_XsNnJBZz9E7w@mail.gmail.com>
Message-ID: <dec18f48f7cb86142a5ba86cbde28b9f@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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