Re: #[Deprecated] Attribute

From: Date: Wed, 13 Jan 2021 12:46:54 +0000
Subject: Re: #[Deprecated] Attribute
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-112869@lists.php.net to get a copy of this message
On Wed, Jan 13, 2021 at 1:34 PM Marco Pivetta <ocramius@gmail.com> wrote: > On Sun, Jan 10, 2021 at 2:48 AM G. P. B. <george.banyard@gmail.com> wrote: > >> Just to clarify this raises an E_DEPRECATED right? >> Could it make sense to raise E_USER_DEPRECATED instead? >> > > I hadn't checked this before, but as per George's message, this is > worrying. > > I've been quite loud about it in the past, but static metadata definitions > should really not lead to runtime side-effects, especially if not pure > (error handling system tripped here). > > I'd be totally for a built-in #[Deprecated] attribute if > it did **NOT** > have a runtime behavior, which is an absolute no-go from my PoV. > > This stuff is easily introspectible via tools like phpstan, psalm, phan, > and does not need to lead to more problematic runtime issues. > I get where you are coming from, but side-effect based notices/deprecations is just the way PHP works at the moment and as such this existing mechanism should be used and extended. I do have (vague) plans to tackle alternative ways to process notices/deprecations in the future, but this is independent from that and #[Deprecated] would automatically tie into a change of this kind. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > >

« previous php.internals (#112869) next »