Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128990
Precedence: list
MIME-Version: 1.0
References: <CAPqq82sqFy1y77XLu8Kbncg18WNopeJdPrfB+JQ8FWNZ4XpTQg@mail.gmail.com>
In-Reply-To: <CAPqq82sqFy1y77XLu8Kbncg18WNopeJdPrfB+JQ8FWNZ4XpTQg@mail.gmail.com>
Date: Tue, 28 Oct 2025 16:43:54 +0100
Message-ID: <CAPyj-LBG0nR75AUMXT0XCnpNnPP=T62NYvRQ34yeZpd+i=cTPw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Add #[NoSerialize] attribute for
 excluding properties or classes from serialization
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Dmytro

On Tue, Oct 28, 2025 at 12:00=E2=80=AFAM Dmytro Kulyk <lnkvisitor.ts@gmail.=
com> wrote:
>
> I=E2=80=99d like to open a discussion about a new proposal introducing th=
e
> #[NoSerialize] attribute, which allows developers to explicitly
> exclude properties =E2=80=94 or even entire classes =E2=80=94 from native=
 PHP
> serialization.
>
> RFC: https://wiki.php.net/rfc/no_serialize_attribute
> Implementation: https://github.com/php/php-src/pull/20074

Thank you for your proposal. I have a few comments.

> When applied to a class, instances will be serialized as NULL.

I don't understand the rationale for diverging from the existing
@not-serializable behavior of internal classes, which throw when
attempted to be serialized (e.g. Random\Engine\Secure). I see there's
also a separate RFC to introduce that behavior:
https://wiki.php.net/rfc/not_serializable_attribute I don't think
there's a need for both of these attributes. To demonstrate, how would
we even decide whether an internal class like PDO should get the
#[NoSerialize] or #[NotSerializable] attribute? Informing the user of
potentially incorrect serialization is the prudent option, and if they
would like to skip the serialization of a property containing a PDO
object they can simply mark it as #[NoSerialize].

The RFC says:

> This approach ensures that data structures containing such objects (for e=
xample, arrays, collections, or parent objects) remain valid and can be saf=
ely unserialized without errors, while clearly indicating that the value wa=
s intentionally omitted.

But is replacing unserializable objects with NULL in nested arrays
really the safe choice? In these cases, I feel like a custom
serializer that consciously replaces the object is warranted. This
might also cause problems for typed properties:

    #[NoSerialize]
    class PDO {}

    class Foo {
        /* Will be happily serialized as NULL, but can't be restored becaus=
e the
         * property is not nullable. */
        public PDO $connection;
    }

To summarize, I'd prefer if #[NoSerialize] on classes would cause
serialize() to throw, like we already do for @not-serializable.

> Class-level #[NoSerialize] is inherited by child classes unless explicitl=
y overridden.

Can you clarify how this would work? How can you override this
attribute by omission?

    #[NoSerialize]
    class Foo {}

    /* What do I add here to remove #[NoSerialize]? */
    class Bar extends Foo {}

> Out of scope: JSON (json_encode(), JsonSerializable) and var_export() rem=
ain unaffected.

Any future attempt to exclude properties marked as #[NoSerialize] from
json_encode() would be backwards incompatible after this RFC has been
implemented. To avoid this BC break, json_encode() would need a
separate attribute (e.g. #[NoJsonEncode]). That sounds reasonable, but
should be spelled out in the RFC.

> Invalid Targets & Compile-Time Diagnostics

What's the rationale for warning for some, but erroring for others?

Ilija