On Wed, Jan 13, 2021 at 1:34 PM Marco Pivetta <ocram...@gmail.com> wrote:
> On Sun, Jan 10, 2021 at 2:48 AM G. P. B. <george.bany...@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/ > >
