Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127908
Precedence: bulk
MIME-Version: 1.0
References: <CALaXqqRKy4_y3HkO6dVhVcOjoHOp=HYdsU7v3SVZQ8kr1EfgLA@mail.gmail.com>
 <CALaXqqSPwzfvnNs=xyenP9+KJ9wC5p4nBXdmzjCezpMpzoFCYg@mail.gmail.com> <96e5addb-1570-4b4f-9915-c3fc55988f24@app.fastmail.com>
In-Reply-To: <96e5addb-1570-4b4f-9915-c3fc55988f24@app.fastmail.com>
Date: Sat, 5 Jul 2025 12:53:02 -0700
Message-ID: <CALaXqqTZyRYh_Kw=nTZNQPWgPar+0sb8kEJbRJ2v8_n2MhSM0A@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] [Discussion] #[\DelayedTargetValidation] attribute
To: Rob Landers <rob@bottled.codes>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000170cf8063933f728"
From: daniel.e.scherzer@gmail.com (Daniel Scherzer)

--000000000000170cf8063933f728
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 4, 2025 at 4:50=E2=80=AFPM Rob Landers <rob@bottled.codes> wrot=
e:

>
> On Sun, Jun 22, 2025, at 22:00, Daniel Scherzer wrote:
>
> On Tue, Jun 17, 2025 at 4:26=E2=80=AFPM Daniel Scherzer <
> daniel.e.scherzer@gmail.com> wrote:
>
> Hi internals,
>
> I'd like to start the discussion for a new RFC about adding a
> `#[\DelayedTargetValidation]` attribute.
>
> * RFC: https://wiki.php.net/rfc/delayedtargetvalidation_attribute
> * Implementation: https://github.com/php/php-src/pull/18817
>
> --Daniel
>
>
>
> It seems a common point of discussion is the difference in behavior
> between internal and userland attributes, so I wanted to clarify a few
> things:
>
> * Userland attributes are always metadata, in part because of the
> backwards and forward compatibility that those attributes provide - the
> attribute does not need to exist in order to be used, it just needs to
> exist (and target the location) when you call
> ReflectionAttribute::newInstance() to instantiate
> * Internal attributes are a mix between metadata and a way to plug into
> the engine. There were already existing ways to plug into the engine (e.g=
.
> using magic methods or implementing the Countable or ArrayAccess
> interfaces) but attributes provided a way to plug into the engine when yo=
u
> don't just want to add a function override, but rather something else (li=
ke
> indicating a parameter should be redacted in backtraces with
> `#[\SensitiveParameter]`). It would probably be impossible to do that
> securely with a userland attribute and userland error handler that manual=
ly
> redacted things...
> * Attributes were designed to have good compatibility - the syntax chosen
> for PHP 8.0 was, in prior versions of PHP, used for comments - so any cod=
e
> with attributes could also work in PHP 7.4, just without the metadata.
> Similarly, by not validating userland attributes until they are accessed
> with reflection, you can add an attribute that does not exist yet (e.g. i=
f
> using different versions of a library) with minimal complications.
> * Internal attributes are validated at compile time - because they can be=
.
> Internal attributes tell the engine to do something, and it makes sense (=
at
> least to me) that if the engine cannot do that thing, there should be an
> error without needing to wait for ReflectionAttribute::newInstance() to b=
e
> called.
>
> But, the validation of internal attributes at compile time means that the=
y
> lose the compatibility features of userland attributes, and that is what
> this RFC is trying to address. To be clear, I think the difference in
> behavior between userland and internal attributes is a) fundamentally bas=
ed
> on the difference in capabilities (pure metadata vs engine behavior) and =
b)
> something that should not be changed without significant further
> investigation.
>
>
> I don=E2=80=99t think this is quite right. Because non-existent attribute=
s can be
> used, if you use attributes in your library, you already know to only eve=
r,
> and I mean only ever, instantiate your own attributes. Attempting to
> instantiate someone else=E2=80=99s attributes can result in crashes. This=
 means any
> delayed attributes will most likely never be validated by anything.
>
>
Symfony instantiates arbitrary attributes,
https://github.com/symfony/symfony/pull/40307 - and while delayed
attributes may not end up being validated, that is a feature, not a bug -
the goal is that the validation not be performed at compile time, and so it
was either delay to runtime, or not do the validation at all.


>
> This new `#[\DelayedTargetValidation]` is meant to simplify things, and t=
o
> partially unify the behavior of the errors - if you are getting any error=
s
> from internal attributes and want to suppress them at compile time, just
> add the new attribute everywhere.
>
> -Daniel
>
>
> I don=E2=80=99t think this is =E2=80=9Cforward compatibility=E2=80=9D, th=
is is completely
> disabling the attribute.
>
> =E2=80=94 Rob
>


So I guess my use of "forward compatibility" was a bit confusing. This
allows a library to be backwards compatible (using PHP 8.6 attribute
targets but running on PHP 8.5 without errors) by making the language
forward compatible (allowing PHP 8.5 to process 8.6 attribute targets
without errors, by delaying those errors). The attribute is not disabled at
all though.

* If the attribute is used in a place where it would do anything (i.e.
there wouldn't be an error about being a bad target) then that attribute is
used as normal, and #[\DelayedTargetValidation] does not affect it
* If the attribute is used in a place where it would error, then it already
cannot do anything, and #[\DelayedTargetValidation] just delays the error -
the attribute is already going to be inactive anyway

-Daniel

--000000000000170cf8063933f728
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Jul 4, 2025 at 4:50=E2=80=AFPM Ro=
b Landers &lt;rob@bottled.codes&gt; wrote:</div><div class=3D"gmail_quote g=
mail_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u>=
</u><div><div><br></div><div>On Sun, Jun 22, 2025, at 22:00, Daniel Scherze=
r wrote:</div><blockquote type=3D"cite" id=3D"m_-4172391421794481088qt"><di=
v dir=3D"ltr"><div dir=3D"ltr">On Tue, Jun 17, 2025 at 4:26=E2=80=AFPM Dani=
el Scherzer &lt;<a href=3D"mailto:daniel.e.scherzer@gmail.com" target=3D"_b=
lank">daniel.e.scherzer@gmail.com</a>&gt; wrote:</div><div><blockquote styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div>Hi internals,</div><div><br></div><div>I&=
#39;d like to start the discussion for a new RFC about adding a `#[\Delayed=
TargetValidation]` attribute.</div><div><br></div><div>* RFC:=C2=A0<a href=
=3D"https://wiki.php.net/rfc/delayedtargetvalidation_attribute" target=3D"_=
blank">https://wiki.php.net/rfc/delayedtargetvalidation_attribute</a></div>=
<div>* Implementation:=C2=A0<a href=3D"https://github.com/php/php-src/pull/=
18817" target=3D"_blank">https://github.com/php/php-src/pull/18817</a></div=
><div><br></div><div>--Daniel</div></div></blockquote><div><br></div><div><=
br></div><div>It seems a common point of discussion is the difference in be=
havior between internal and userland attributes, so I wanted to clarify a f=
ew things:</div><div><br></div><div>* Userland attributes are always metada=
ta, in part because of the backwards and forward compatibility=C2=A0that th=
ose attributes provide - the attribute=C2=A0does not need to exist in order=
 to be used, it just needs to exist (and target the location) when you call=
 ReflectionAttribute::newInstance() to instantiate</div><div>* Internal att=
ributes are a mix between metadata and a way to plug into the engine. There=
 were already existing ways to plug into the engine (e.g. using magic metho=
ds or implementing the Countable or ArrayAccess interfaces) but attributes =
provided a way to plug into the engine when you don&#39;t just want to add =
a function override, but rather something else (like indicating a parameter=
 should be redacted in backtraces with `#[\SensitiveParameter]`). It would =
probably be impossible to do that securely with a userland attribute and us=
erland error handler that manually redacted things...</div><div>* Attribute=
s were designed to have good compatibility - the syntax chosen for PHP 8.0 =
was, in prior versions of PHP, used for comments - so any code with attribu=
tes could also work in PHP 7.4, just without the metadata. Similarly, by no=
t validating userland attributes until they are accessed with reflection, y=
ou can add an attribute that does not exist yet (e.g. if using different ve=
rsions of a library) with minimal complications.</div><div>* Internal attri=
butes are validated at compile time - because they can be. Internal attribu=
tes tell the engine to do something, and it makes sense (at least to me) th=
at if the engine cannot do that thing, there should be an error without nee=
ding to wait for ReflectionAttribute::newInstance() to be called.</div><div=
><br></div><div>But, the validation of internal attributes at compile time =
means that they lose the compatibility features of userland attributes, and=
 that is what this RFC is trying to address. To be clear, I think the diffe=
rence in behavior between userland and internal attributes is a) fundamenta=
lly based on the difference in capabilities (pure metadata vs engine behavi=
or) and b) something that should not be changed without significant further=
 investigation.</div></div></div></blockquote><div><br></div><div>I don=E2=
=80=99t think this is quite right. Because non-existent attributes can be u=
sed, if you use attributes in your library, you already know to only ever, =
and I mean only ever, instantiate your own attributes. Attempting to instan=
tiate someone else=E2=80=99s attributes can result in crashes. This means a=
ny delayed attributes will most likely never be validated by anything.</div=
><div><br></div></div></blockquote><div><br></div><div>Symfony instantiates=
 arbitrary attributes,=C2=A0<a href=3D"https://github.com/symfony/symfony/p=
ull/40307">https://github.com/symfony/symfony/pull/40307</a> - and while de=
layed attributes may not end up being validated, that is a feature, not a b=
ug - the goal is that the validation not be performed at compile time, and =
so it was either delay to runtime, or not do the validation at all.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>=
</div><blockquote type=3D"cite" id=3D"m_-4172391421794481088qt"><div dir=3D=
"ltr"><div><div><br></div><div>This new `#[\DelayedTargetValidation]` is me=
ant to simplify things, and to partially unify the behavior of the errors -=
 if you are getting any errors from internal attributes and want to suppres=
s them at compile time, just add the new attribute everywhere.</div><div><b=
r></div><div>-Daniel=C2=A0</div></div></div></blockquote><div><br></div><di=
v>I don=E2=80=99t think this is =E2=80=9Cforward compatibility=E2=80=9D, th=
is is completely disabling the attribute.</div><div><br></div><div id=3D"m_=
-4172391421794481088sig121229152">=E2=80=94 Rob</div></div></blockquote><di=
v><br></div><div><br></div><div>So I guess my use of &quot;forward compatib=
ility&quot; was a bit confusing. This allows a library to be backwards comp=
atible (using PHP 8.6 attribute targets but running on PHP 8.5 without erro=
rs) by making the language forward compatible (allowing PHP 8.5 to process =
8.6 attribute targets without errors, by delaying those errors). The attrib=
ute is not disabled at all though.</div><div><br></div><div>* If the attrib=
ute is used in a place where it would do anything (i.e. there wouldn&#39;t =
be an error about being a bad target) then that attribute is used as normal=
, and #[\DelayedTargetValidation] does not affect it</div><div>* If the att=
ribute is used in a place where it would error, then it already cannot do a=
nything, and #[\DelayedTargetValidation] just delays the error - the attrib=
ute is already going to be inactive anyway</div><div><br></div><div>-Daniel=
</div><div>=C2=A0</div></div></div>

--000000000000170cf8063933f728--