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

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.

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

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]: Code search results · GitHub