On Tue, 27 May 2025 at 20:05, Ben Ramsey <ram...@php.net> wrote: > > On Jan 13, 2021, at 06:43, Benjamin Eberlei <kont...@beberlei.de> wrote: > > > > On Wed, Jan 13, 2021 at 1:05 PM Brent Roose <bre...@stitcher.io> wrote: > > > >> Hi Sara > >> > >>> On 22 Dec 2020, at 19:54, Sara Golemon <poll...@php.net> wrote: > >>> > >>> On Tue, Dec 22, 2020 at 12:35 PM Nicolas Grekas < > >>> nicolas.grekas+...@gmail.com> wrote: > >>> > >>>> It would be great to allow adding this attribute on classes. What > about > >>>> allowing it right now and not bind it to any runtime side-effect? That > >>>> would allow static analyzers to do their job. Same for consts and > >>>> properties by the way. > >>>> > >>>> Also, it would be very useful to add named parameters to the > attribute, > >>>> namely: "package" (the name of the package that declares the > deprecation) > >>>> and "version" (the version of that package that introduced the > >>>> deprecation), next to the message. > >>>> > >>>> This is critical info when building reports of deprecations. > >>>> > >>>> > >>> You could do that now with a polyfill from userspace. If the annotation > >>> need not have an effect, then it's just any other userspace > implementation. > >> > >> The difference is that PHP core has the ability to force standarization. > >> There's already JetBrains' implementation of #[Deprecated], which Psalm > and > >> PhpStan also support, but it's not a real standard. Maybe the FIG would > one > >> day step in to decide these kinds of things, but the reality is that > many > >> major frameworks don't follow FIG as closely as they used to. I think > >> there's value in adding attributes in the core, with the goal only being > >> static analysis. It'll allow for consistency and that's a valuable > thing. > >> > > > > I want to keep #[Deprecated] on other elements than functions / methods > out > > of this RFC, because they require entirely different implementation > > approaches. > > > > We identified in the PR already that this should at some point be > > standardized in core, because internal attributes will currently not be > > able to support extension through inheritance by userland for > > implementation reasons. > > > > My next RFC update will reflect this future scope. > > > Last night, I identified a need for `#[Deprecated]` on a userland class in > one of my libraries, but I had to settle on `@deprecated` for the widest > range of compatibility. > > Has there been anymore thought on putting together an implementation for > this? I’m happy to draft an RFC if someone is able to help with the > implementation. I don’t understand the complexities around the > implementation, but is this something that could make it into 8.5, provided > an RFC vote passes? > > Cheers, > Ben > > I have needed this as well at work for a shared library and i'm sure many library authors would use it too. Current IDE's like jetbrains has support for #[Deprecated($reason, $replacement)] which will throw warning in the IDE, see their implementation here: https://github.com/JetBrains/phpstorm-attributes?tab=readme-ov-file#deprecated
If this could be supported at a language level, package authors, frameworks and internal company libraries would benefit from it. I see no reason why anyone would be against the idea, other than pure chaos evil.
