Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112601
MIME-Version: 1.0
References: <CAEPJdu=kopidV44A01Sjv_eLq_fkLsjVuzqXx+j9b9gCahn2Vg@mail.gmail.com>
In-Reply-To: <CAEPJdu=kopidV44A01Sjv_eLq_fkLsjVuzqXx+j9b9gCahn2Vg@mail.gmail.com>
Date: Tue, 22 Dec 2020 19:34:53 +0100
Message-ID: <CAOWwgpmwdxnwb+NcHcd59ySwbKKB_1C1nYtPeGkmPXa8F3GXPg@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006d027705b711d58f"
Subject: Re: [PHP-DEV] #[Deprecated] Attribute
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--0000000000006d027705b711d58f
Content-Type: text/plain; charset="UTF-8"

Hi Benjamin,

I have updated the RFC for a #[Deprecated] attribute that wasn't completed
> for PHP 8.0 due to time constraints and I am able to restart the discussion
> now.
>
> https://wiki.php.net/rfc/deprecated_attribute
>
> The following updates have been made:
>
> - focus on only method and function deprecations for now, removed
> class/property/constant deprecations.
> - a section on explaining the runtime effects of deprecations in PHP, and a
> note that this RFC is about completing deprecation support within the
> existing model, while changes to deprecations in general are out of scope /
> a disjunct concern for a different RFC.
>
> Sara proposed a much improved implementation over my initial patch, by
> using the already existing ZEND_ACC_DEPRECATED constant on userland
> functions. The resulting implementation is therefore much simpler and
> really just extending existing function deprecation support from internal
> to userland functions. You can find the PR here:
>
> https://github.com/php/php-src/pull/6521
>

Thanks for the RFC.

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.

Thanks for considering,
Nicolas

--0000000000006d027705b711d58f--