Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127526 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 542141A00BC for ; Sun, 1 Jun 2025 22:31:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1748816988; bh=vkg74zAoeFeUamQF3kHDIqoedidmgCH6k/6CJeRz69U=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=AlZ6kNYqgrI2qkg5dbt19xDZmu4jEQFCzpTIx1eCLuls6Cvzjpx2wC+lUxGBCNr01 6AF0byhpNEWx/dClPt49VetKwfRoptjuJbAebf4sB2isoNvmk8jb6GsPepXBw/Ggxn n3WKYf3WZHPnvWKQzTq8uLP22MjwWuAFIQki+CNmSAIb/4tJ+ypqsnm7n2CRUNsZkO xOvRl7IN14QdXbJ5IPbFvXEomYi/Kq/KAtVl7vwBjgR9utQ3kMjZkIMlld9duAEZ5k c7TmrRirgl7bPmrAqP0alqjVCtzpdSNiAOt23nw48oxnBQlMOkWjMIsHQDRTWfBvYS 5eKH0YXjjGMtg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 81E30180068 for ; Sun, 1 Jun 2025 22:29:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 1 Jun 2025 22:29:34 +0000 (UTC) Received: by mail-pg1-f174.google.com with SMTP id 41be03b00d2f7-b2c41acd479so2494574a12.2 for ; Sun, 01 Jun 2025 15:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748817098; x=1749421898; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vkg74zAoeFeUamQF3kHDIqoedidmgCH6k/6CJeRz69U=; b=M+hVPApMuXhO1qV7a+yGABfFyyVeBDLD5XsHJGhwjYZuHeM8eQ6PSPAj6KmTlj49Kg 5FDz+tXgaArPQrrGda+2jhTnmxw48/bAJr2gmQb6yX3moazS6ZnBe+GSaBtjb/Kt5VBr ejEnvNWlC7jGbcurZOrkBJCQzUhZpwQ3WD25w3QgfYSdYduAD4QJpKY6ZEHdCJChPfTh Wsvv+0xQHKgVHMEZfkTo8LLlwTofBsWQLdplXB/r6os1OBmm04si0YhwUYwEF+/80TES ovRty1wbQ891sHYwPWdjtI9bWZYHybLU5d3BUl2A8U1ba34MujP73C0GU805GPQDOMLP qO/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748817098; x=1749421898; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vkg74zAoeFeUamQF3kHDIqoedidmgCH6k/6CJeRz69U=; b=kbFZ9E+9Xo8Yp/ZOre6hdXn+H2/C5R7a33nSu8N+2KjbAdQvJpIztVUKP9MlwHUmvB I04HQ5CSUndcvYZGLMVnhO7Y+x0XhK4YyuofPHztZxZw7kLI20EDSq8Mcc3/TxZmmDSD kPg07GwDBAYamf7/J13ZUevMcI9+t46NlTPp7iBDQNGbNhxYIFrPeqVI4U2PW66/9pwt GFxX5eS6gL3cWc0p1xvZh8DuwDBgGDGsMrku1xZ5h/m9osmOOwBdLeqfwUAgLuAp/qws wm8uZt51ER+O31wYzGwQU1kNuvpM+SR32i3GY+Hata9NeWfrKUx9hfud3Vakckv6k3Nh MrAQ== X-Gm-Message-State: AOJu0YxBuZZjyPLIkf2TgozD0zgmvu+MT/l7y5Z0sbimC5QLErLUgvXc azyFrMuLkRKC9DZMUoqO88qDsytm2DzT2FgmbPoTvnKfrllw9r8n29H4Sm0EHAK2HAUnIvQaYtw eKDUG66y1bM61/wH73EVkSym6V97CRSvV3u22 X-Gm-Gg: ASbGncvzKwJtA1nomUTimSqxlx6gI8vjxK6pxAO+rIFvYjEVIO2fIL6ORf7Eum3Irn2 KY7zILSVPLeXNTzOqP2m2JxcaV3qY0YbFjTz45Xjgurl3spGN3cI5b51HnkR7kr2PIZkk0+0At1 jxwG+PNLafr93QnSLHA7tp2QHaKMnKkzVW X-Google-Smtp-Source: AGHT+IETBA9tQLxdwNdI/2wiDpXWb3VDjR793XgG4UNcAgPB9a3Dy2QSM1XNS2CBzkMvLm3KtPFBIpkiNHUrwu/OM7E= X-Received: by 2002:a17:90b:510a:b0:311:f05b:8695 with SMTP id 98e67ed59e1d1-3127c74302fmr8373126a91.23.1748817098011; Sun, 01 Jun 2025 15:31:38 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <329A033B-585E-45CD-8171-D0CE8334A8B2@php.net> In-Reply-To: <329A033B-585E-45CD-8171-D0CE8334A8B2@php.net> Date: Sun, 1 Jun 2025 23:31:01 +0100 X-Gm-Features: AX0GCFvkHWbg0sfVi6Tpzxb738BTR80tdf0oepf5OgHwviiNElgtTfI_z3ESxLQ Message-ID: Subject: Re: [PHP-DEV] #[Deprecated] Attribute To: Ben Ramsey Cc: PHP Internals Content-Type: multipart/alternative; boundary="000000000000e77cd206368a35cd" From: fenniclog@gmail.com (fennic log) --000000000000e77cd206368a35cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 27 May 2025 at 20:05, Ben Ramsey wrote: > > On Jan 13, 2021, at 06:43, Benjamin Eberlei wrote= : > > > > On Wed, Jan 13, 2021 at 1:05 PM Brent Roose wrote: > > > >> Hi Sara > >> > >>> On 22 Dec 2020, at 19:54, Sara Golemon wrote: > >>> > >>> On Tue, Dec 22, 2020 at 12:35 PM Nicolas Grekas < > >>> nicolas.grekas+php@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? Th= at > >>>> 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 annotati= on > >>> need not have an effect, then it's just any other userspace > implementation. > >> > >> The difference is that PHP core has the ability to force standarizatio= n. > >> There's already JetBrains' implementation of #[Deprecated], which Psal= m > and > >> PhpStan also support, but it's not a real standard. Maybe the FIG woul= d > 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 bei= ng > >> 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 i= n > 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=E2=80=99m happy to draft an RFC if someone is able to help with t= he > implementation. I don=E2=80=99t understand the complexities around the > implementation, but is this something that could make it into 8.5, provid= ed > 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=3Dreadme-ov-file#depre= cated 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. --000000000000e77cd206368a35cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 27 May = 2025 at 20:05, Ben Ramsey <ramsey@php.= net> wrote:
> On Jan 13, 2021, at 06:43, Benjamin Eberlei <kontakt@beberlei.de> wrote: >
> On Wed, Jan 13, 2021 at 1:05 PM Brent Roose <brendt@stitcher.io> wrote:
>
>> Hi Sara
>>
>>> On 22 Dec 2020, at 19:54, Sara Golemon <pollita@php.net> wrote:
>>>
>>> On Tue, Dec 22, 2020 at 12:35 PM Nicolas Grekas <
>>> nicolas.grekas+php@gmail.com> wrote:
>>>
>>>> It would be great to allow adding this attribute on classe= s. 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 con= sts and
>>>> properties by the way.
>>>>
>>>> Also, it would be very useful to add named parameters to t= he 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 deprecation= s.
>>>>
>>>>
>>> You could do that now with a polyfill from userspace. If the a= nnotation
>>> need not have an effect, then it's just any other userspac= e implementation.
>>
>> The difference is that PHP core has the ability to force standariz= ation.
>> 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 th= at 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 / method= s 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 b= e
> 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 ra= nge of compatibility.

Has there been anymore thought on putting together an implementation for th= is? I=E2=80=99m happy to draft an RFC if someone is able to help with the i= mplementation. I don=E2=80=99t understand the complexities around the imple= mentation, but is this something that could make it into 8.5, provided an R= FC vote passes?

Cheers,
Ben


I have needed this as well at work for= a shared library and i'm sure=C2=A0many library authors would use it t= oo.
Current IDE's like jetbrains has support for #[Deprecated= ($reason, $replacement)] which will throw warning in the IDE,=C2=A0
see their implementation=C2=A0here:=C2=A0https://githu= b.com/JetBrains/phpstorm-attributes?tab=3Dreadme-ov-file#deprecated

If this could be supported at a language level, packa= ge authors, frameworks and internal company libraries would benefit=C2=A0fr= om it.
I see no reason why anyone would be against the idea, othe= r than pure chaos evil.


--000000000000e77cd206368a35cd--