Le mer. 18 juin 2025 à 23:49, Ilija Tovilo <tovilo.il...@gmail.com> a écrit :
> Hi Volker > > On Wed, Jun 18, 2025 at 2:23 PM Volker Dusch <vol...@tideways-gmbh.com> > wrote: > > > > On Wed, Jun 18, 2025 at 1:28 AM Daniel Scherzer < > daniel.e.scher...@gmail.com> wrote: > >> > >> 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 > > > > > > While I'm in favor of the RFC, I'd more like to see the default behavior > of internal and userland attributes adjusted to work the same, with both > having delayed validation enabled by default. Treating core attributes > differently doesn't make sense to me. > > > > So, if that's someone you're willing to work on, I'd very much prefer > that. > I 100% agree with what Volker posted here. I wouldn't support that, because internal attributes with effects are > not usually instantiated. > > class C { > #[\SensitiveParameter] // This doesn't actually do anything, only > works on parameters > public $prop; > } > > I would get no indication that this attribute doesn't behave as I > expect. We have at least a few attributes with confusable targets > (SensitiveParameter, Override, Deprecated, NoDiscard). User attributes > can't have effects without at least reading them through reflection, > although granted they don't necessarily need to be instantiated, and > so might also not trigger the error. > These considerations work exactly the same for userland attributes: if I use #[Whatever] on a location that is not allowed by the declaration of the attribute, nothing will ever tell me at runtime, because nobody will ever try to read that attribute on that unexpected location. Yet, this "silent" behavior is by design, because that's the core of the "attributes are declarative metadata" promise. If you make them be enforced by the engine, then this promise falls apart and attributes become way less useful. The correct solution to the validation problem is to use a static analyzer. There, one can easily spot that some attributes are not correctly placed, and one can then also *ignore* the report of the SA tool, because eg #[Deprecated] is used on a class on purpose for that library (e.g. for the forward compat use case). The exception to the declarative nature of attributes that is currently allowed for engine-provided ones is detrimental to me: it allows turning them into "syntax hacks" basically (=engine-enforced-thus-not-declarative rules). To paraphrase Volker, I'm in favor of the RFC, but only if we cannot agree on the need for internal and userland attributes to have the same conceptual roots (truly declarative ones). Cheers, Nicolas
