[PHP-DEV] [VOTE] RFC: #[\DelayedTargetValidation] attribute

Mailing Lists php.internals
1

Hi internals,

Voting is now open for this RFC.

Voting will end 2025-07-31 at end-of-day UTC.

-Daniel

2

On Thu, Jul 17, 2025 at 9:21 AM Daniel Scherzer <daniel.e.scherzer@gmail.com> wrote:

Hi internals,

Voting is now open for this RFC.

Voting will end 2025-07-31 at end-of-day UTC.

-Daniel

For those who are still debating how to vote, or who voted no, I want to highlight the “Extend #[\Override] to target properties” RFC currently in voting as an example of a use case. See https://wiki.php.net/rfc/override_properties.

Specifically, if we had already added #[\DelayedTargetValidation] as part of 8.4, and that other RFC passes, there would have been a place to use it - on class properties in code that supports 8.4 and 8.5 but wants to indicate that the property overrides a parent property. Fundamentally, #[\DelayedTargetValidation] needs to be introduced before it is useful, because it is designed for supporting attributes that change in future versions of PHP. Introducing it in 8.5 might not help for #[\Override] on property, but it would help for any attribute changes in 8.6+, e.g. if #[\Override] starts to support class constants.

-Daniel

3

Le lun. 21 juil. 2025 à 20:23, Daniel Scherzer <daniel.e.scherzer@gmail.com> a écrit :

On Thu, Jul 17, 2025 at 9:21 AM Daniel Scherzer <daniel.e.scherzer@gmail.com> wrote:

Hi internals,

Voting is now open for this RFC.

Voting will end 2025-07-31 at end-of-day UTC.

-Daniel

For those who are still debating how to vote, or who voted no, I want to highlight the “Extend #[\Override] to target properties” RFC currently in voting as an example of a use case. See https://wiki.php.net/rfc/override_properties.

Specifically, if we had already added #[\DelayedTargetValidation] as part of 8.4, and that other RFC passes, there would have been a place to use it - on class properties in code that supports 8.4 and 8.5 but wants to indicate that the property overrides a parent property. Fundamentally, #[\DelayedTargetValidation] needs to be introduced before it is useful, because it is designed for supporting attributes that change in future versions of PHP. Introducing it in 8.5 might not help for #[\Override] on property, but it would help for any attribute changes in 8.6+, e.g. if #[\Override] starts to support class constants.

I voted in favor of the RFC precisely because of this capability, which is very much needed in code bases I deal with. Not having this will force us, authors, to create workarounds based on eg @annotations. Worst is that these workarounds will have to remain for a never ending amount of time as new attributes are introduced to the engine.

Nicolas

4

Am 17.07.2025, 18:21:10 schrieb Daniel Scherzer <daniel.e.scherzer@gmail.com>:

Hi internals,

Voting is now open for this RFC.

Voting will end 2025-07-31 at end-of-day UTC.

-Daniel

As one of the original attributes RFC authors, I have voted yes on this and hope it passes.

its unfortunate that we need to do this, because its a bit of a hacky solution, but its entirely the vault of the original implementation, we didn’t think of this.

And that we didn’t think of it during the Deprecated RFC as well and already set the target validation to the max and just not do anyhting with the attribute.

I think a better fix could be to delay target validation automatically to the point when the Engine consumes an attribute, but that would change the original behavior and not sure if that would get a majority, so an opt-in approach is the least bad solution to fix this shortcoming. Another solution, since this will work only with new attributes, would be more informal: that we set target=all for compiler attributes from now on, at least for attributes where we think they could expand in targets in the future.

greetings
Benjamin

5

On Thu, Jul 17, 2025 at 9:21 AM Daniel Scherzer <daniel.e.scherzer@gmail.com> wrote:

Hi internals,

Voting is now open for this RFC.

Voting will end 2025-07-31 at end-of-day UTC.

-Daniel

The vote was successful, with 14 in favor and 6 against.

-Daniel