Thanks for the feedback.
> Thank you for your RFC. It is really well-written and nicely explains
> the various (edge) cases. I've only read through the `#[\NoSerialize]`
> one, since it is the topic of this RFC discussion. I agree with Ilija on
> all points.
>
> Am 2025-10-29 15:35, schrieb Dmytro Kulyk:
> > #[NoSerialize], on the other hand, would apply to wrappers,
> > containers, or domain objects where serialization of the rest of the
> > structure should continue even if one field or nested object cannot be
> > meaningfully serialized.
>
> But even for wrappers you can't guarantee that the wrapper is stored in
> a nullable property. When applying the attribute to a field, omitting
> the field makes sense, since the author of the property is the same
> person who is capable of adding the attribute and thus is in full
> control. This is different for classes where the author of the class
> doesn't know how and where the class is being used. I thus agree with
> Ilija that this should throw to clearly indicate that the user of the
> class is doing something incorrect and to not silently corrupt data. If
> an author of a class needs more fine-grained control, they can either
> add the attribute to individual properties themselves - or implement
> `__serialize()`.
>
You are right, this behavior can be non-obvious and lead to unexpected results.
> >> > Class-level #[NoSerialize] is inherited by child classes unless
> >> > explicitly 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 {}
> >
> > Class-level #[NoSerialize] is transparently inherited by child classes.
> > There’s currently no way to override or cancel this behavior in
> > descendants; the attribute remains effective throughout the
> > inheritance chain.
>
> Indeed, however the “unless explicitly overridden” bit in the RFC text
> implies that this is possible.
>
> > As an alternative, #[NotSerializable] could be extended to
> > #[NotSerializable(bool $soft = false)], which would provide the same
> > behavior while keeping it in a separate, more consistent attribute —
> > avoiding the double semantics currently implied by #[NoSerialize].
>
> I don't think that sub classes should be able to make a non-serializable
> parent class serializable, since they clearly won't be able to correctly
> restore the state of the parent class. In fact I would consider this an
> improvement over the existing serialization hooks where the child class
> can simply skip calling the parent's serializer and thus create a
> situation that the parent class does not expect to occur.
It already makes no sense because the class-level attribute will be
excluded from the RFC, and I have no plan to add something like this
to #[NotSerializable]. It may be added in a future RFC.
> > Initially, the idea was to make all of these cases emit warnings, but
> > I didn’t figure out how to implement that consistently within the
> > attribute validators.
> > At this point, I don’t see any practical reason to allow the attribute
> > on unsupported targets, so all such cases will be changed to
> > compile-time errors instead of warnings.
>
> Yes, every clear error that is detectable at compile-time should be a
> hard error to make it easy for users to detect the mistake.
>
Best regards
Dmytro Kulyk
