Hi On 6/10/26 19:02, Nicolas Grekas wrote:
I'd like to open the discussion on a new RFC: https://wiki.php.net/rfc/serializable_closures
Don't forget to link the discussion thread in the RFC. For your convenience: https://news-web.php.net/php.internals/131198
As to the RFC itself: I think it might be useful to split this into two RFCs, similarly to how Volker and I split the initial support for Closures in const-expr into support for Closures and support for first class callables.
Specifically I believe that the proposed serialization format is fragile and the stated security model, which I suspect heavily influenced the design of the serialization format, is probably overly cautious.
I don't think it is a problem to make `unserialize()` a Closure factory, because the created Closure is “inert”. Contrary to arbitrary object unserialization (which will immediately call the deserialization hooks and then later __destruct()), the Closure will not actually do anything unless it is called.
If folks are able to unserialize arbitrary payloads - which is documented to be unsafe - they already have capabilities that are much more powerful than “creating Closures”.
For first class callables specifically, there is a very obvious and stable identifier to use: The underlying function name.
For regular Closures, I don't like how changing something unrelated (namely adding new Closures to a class) can change the meaning of the serialized data. This is not how serialization works right now: The value in question is in full control of its serialization format and is able to “gracefully” support existing serialized payloads using an old format within an unserialization hook (e.g. by including a version number field). This allows to e.g. keep serialized queue jobs working across deploys.
As for the var_export() in the future scope: I think adding support for first class callables to `var_export()` would be a change that can just be done without an RFC. It might be a good first step that might already be helpful to your use case?
Best regards Tim Düsterhus
