Everything

php

[RFC] [Discussion] Attributes on compile-time constants

php.internals

Daniel Scherzer

1 year ago

Hi again,

Based on feedback to my last thread[1] that an RFC would be needed to allow
attributes on constants, I have just filed
https://wiki.php.net/rfc/attributes-on-constants and added it to the "Under
Discussion" section on the main RFC page.

I plan to open the vote in two weeks unless issues arise.

-Daniel

[1] https://news-web.php.net/php.internals/126065

Tim Düsterhus

1 year ago

Hi

On 11/30/24 18:00, Daniel Scherzer wrote:

> Based on feedback to my last thread[1] that an RFC would be needed to allow
> attributes on constants, I have just filed
> https://wiki.php.net/rfc/attributes-on-constants and added it to the "Under
> Discussion" section on the main RFC page.

Thank you for your RFC. As you might have guessed from my comments on
the PR, I quite like the proposal to round off attributes. Nevertheless
any new syntax has quite a bit of an impact on tooling around PHP (see
also (3) below), so I'm curious if you already have any use cases
besides the `#[\Deprecated]` attribute that could be mentioned in the
RFC text?

-----------

Other than that, I have the following remarks to the RFC itself:

1.

”New constant Attribute::TARGET_CONSTANT may conflict with subclasses
that define such a constant of their own.”

This is a non-issue, because the Attribute class is final.

2.

”Extensions that validate the usage of their attributes and use
Attribute::TARGET_ALL may need to be updated.”

This is not just extensions, but also userland code that did not
anticipate any new attribute targets.

3.

The “Backward Incompatible Changes” section should probably shortly
mention that this is new syntax and will need changes to IDEs, static
analysis tools and formatters. The second paragraph in
https://wiki.php.net/rfc/closures_in_const_expr#backward_incompatible_changes
might be a good example.

Best regards
Tim Düsterhus

Daniel Scherzer

1 year ago

On Mon, Dec 2, 2024 at 2:48 PM Tim Düsterhus <tim@bastelstu.be> wrote:

> Thank you for your RFC. As you might have guessed from my comments on
> the PR, I quite like the proposal to round off attributes. Nevertheless
> any new syntax has quite a bit of an impact on tooling around PHP (see
> also (3) below), so I'm curious if you already have any use cases
> besides the `#[\Deprecated]` attribute that could be mentioned in the
> RFC text?
>

I don't have any other use cases at the moment - my primary motivation in
writing this feature was to allow deprecating constants. A few weeks ago I
gave a talk[1] where, among other things, I talked about how I was looking
forward to using the #[Deprecated] attribute, but that there was still room
for improvement since it could not be used on non-class constants. I then
figured: why not try to implement that support myself? And I eventually
figured it out.

> This is a non-issue, because the Attribute class is final.
>

Fixed, thanks

> This is not just extensions, but also userland code that did not
> anticipate any new attribute targets.
>

Given that
1. there isn't (as far as I know) a way to search for everything that has
an attribute
2. there isn't a current way to identify if a constant has an attribute

I didn't think there was anything to actually break for userland
attributes, but I've reworded the note to include userland attributes just
in case.

The “Backward Incompatible Changes” section should probably shortly

> mention that this is new syntax and will need changes to IDEs, static
> analysis tools and formatters. The second paragraph in
>
> https://wiki.php.net/rfc/closures_in_const_expr#backward_incompatible_changes
> might be a good example.
>

Done

-Daniel

[1] https://youtu.be/hGYbXkfbkuU

Tim Düsterhus

1 year ago

Hi

On 12/3/24 15:40, Daniel Scherzer wrote:

>> This is not just extensions, but also userland code that did not
>> anticipate any new attribute targets.
>>
>
> Given that
> 1. there isn't (as far as I know) a way to search for everything that has
> an attribute
> 2. there isn't a current way to identify if a constant has an attribute
>
> I didn't think there was anything to actually break for userland
> attributes, but I've reworded the note to include userland attributes just
> in case.

Here's an example of a userland library that collects attributes as a
“build time” step:

https://github.com/olvlvl/composer-attribute-collector

If that library is updated to understand attributes on constants and a
user applies a TARGET_ALL attribute on a constant, then this case would
apply.

Even if it ultimately is “just in case”, it’s nevertheless helpful to
spell out all possible caveats for the reader to make an informed
decision about the RFC. So thank you for the update :-)

------------

With the updated version, I don't have any further comments about your
RFC text.

Best regards
Tim Düsterhus

Daniel Scherzer

1 year ago

On Sat, Nov 30, 2024 at 9:00 AM Daniel Scherzer <daniel.e.scherzer@gmail.com>
wrote:

> Hi again,
>
> Based on feedback to my last thread[1] that an RFC would be needed to
> allow attributes on constants, I have just filed
> https://wiki.php.net/rfc/attributes-on-constants and added it to the
> "Under Discussion" section on the main RFC page.
>
> I plan to open the vote in two weeks unless issues arise.
>
> -Daniel
>
> [1] https://news-web.php.net/php.internals/126065
>

It has now been just over 2 weeks since I filed the RFC, and over a week
since the last discussion point was resolved. Barring any surprises, I plan
to open the RFC for a vote tomorrow.

-Daniel