Re: [RFC] [Discussion] #[\DelayedTargetValidation] attribute
| From: | Ilija Tovilo | Date: | Wed, 18 Jun 2025 21:47:41 +0000 |
| Subject: | Re: [RFC] [Discussion] #[\DelayedTargetValidation] attribute | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-127715@lists.php.net to get a copy of this message | ||
Hi Volker
On Wed, Jun 18, 2025 at 2:23 PM Volker Dusch <volker@tideways-gmbh.com> wrote:
>
> On Wed, Jun 18, 2025 at 1:28 AM Daniel Scherzer <daniel.e.scherzer@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 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.
Ilija