On Wed, May 22, 2024 at 9:33 AM Nicolas Grekas <nicolas.grekas+...@gmail.com> wrote:
> Hi Benjamin, > > The vote for the RFC #[\Deprecated] attribute is now open: >> >> https://wiki.php.net/rfc/deprecated_attribute >> >> Voting will close on Wednesday 5th June, 08:00 GMT. >> > > I voted "no" because I think this is better addressed in userland, as this > gives more flexibility. > I would better have an attribute that is made only for static analysis > with no runtime side effects at all. > Being forced to make the attribute final because the implementation in the > engine requires is an example of why the engine is not the correct place to > send this notice. Another example is not being able to add the attribute on > classes because [engine reasons]. > This is a misrepresentation of what this RFC is. There are no engine reasons for not being able to set it on classes. It just has not been implemented yet. Allowing deprecations on classes is something that needs to be figured out in a separate RFC in how these semantics work. Then adding Deprecated attribute would just be a trivial matter. You could argue about the order of things, we could have first made an RFC for deprecated classes, but we should avoid a waterfall process of dependencies in things to do in the language. > > trigger_error() is better fitted for the runtime side-effect when it's > desired. > In my opinion, #[Deprecated] should be only for static analysers / > reflection (although this would need another discussion - I'm not sure this > would benefit being in the engine vs in a userland package. > This is the same as above, changing how deprecations work in the engine is orthogonal to this attribute. These attributes are concerned with tagging code elements with flags that the engine already provides, already makes available for internal code elements. > > Thanks for the RFC anyway. > > Nicolas >
