[RFC Proposal] Add #[NoSerialize] attribute for excluding properties from serialization

php.internals

Дмитрий Кулик

330 days ago
This proposal introduces a new attribute, #[NoSerialize], that can be applied to class properties to explicitly exclude them from serialization when using PHP’s built-in serialization mechanisms. # Motivation When developing complex objects, it’s often necessary to exclude specific properties from serialization — for example, resources, closures, database connections, or transient caches. Currently, developers must manually implement __serialize() / __sleep() to filter these properties, which can lead to boilerplate code and potential maintenance errors. Adding a native attribute would provide a simple and declarative way to express this intention directly in code. ```php class Example { public string $name; #[NoSerialize] public $connection; // e.g., PDO, socket, or any transient resource } ``` When serialize($example) is called, $connection would be excluded automatically. # Benefits - Reduces boilerplate for common use cases. - Makes serialization intent explicit and self-documenting. - Simplifies framework and library code that relies on serialization # Implementation Sketch Internally, the engine could mark properties with a flag (e.g., ZEND_ACC_NO_SERIALIZE) during class compilation. During serialization, such properties would be skipped automatically unless overridden by user-defined serialization logic. Best regards, Dmytro Kulyk

Ilija Tovilo

330 days ago
Hi Dmytro Thanks for your proposal. This seems like a reasonable use of attributes. On Mon, Oct 6, 2025 at 12:16 AM Dmytro Kulyk <lnkvisitor.ts@gmail.com> wrote:
> > This proposal introduces a new attribute, #[NoSerialize], that can be > applied to class properties to explicitly exclude them from > serialization when using PHP’s built-in serialization mechanisms.
A few things: * How does this interact with inheritance, i.e. is this flag inherited to overridden child properties? I would assume no, as with other attributes. But it would be good to spell it out. * There are other forms of serialization, most notably JSON and var_export(). Are these affected in any way? Does it make sense to have a universal solution? * There may also be a benefit to marking classes as entirely not serializable, which would throw when encountering the class during [un]serialization. We have some of those internally. [^1] Ilija [^1]: https://github.com/search?q=repo%3Aphp%2Fphp-src%20%40not-serializable&type=code