On Mon, May 22, 2023 at 1:01 PM Dan Ackroyd <dan...@basereality.com> wrote:
> Even for those who use static analysis, most (afaik) don't have it > running constantly in local development and this RFC would prevent > people wondering why their code is behaving surprisingly before it is > static analysed. > It takes care of one possible surprise they might encounter as a result of not running static analysis of their code prior to runtime. Just one, out of dozens of possible types of inference which are done by static analysis checks and could hypothetically be done by PHP at runtime. But I'd question whether there's an appetite out there in general to start adding all sorts of new runtime checks, which I would argue means any new runtime check warrants the utmost consideration of cost-benefit. > Also, not everyone uses static analysis tools. > That's because PHP is a dynamic language which doesn't have an explicit compilation step and by extension where static analysis of any sort is optional. That's my question around the benefit with this RFC; either you use static analysis tools as part of your PHP workflow, because you care about that stuff, or you don't. If you do, you don't need any new error or warning emitting behaviour added to the engine itself, you just need PHPStan / Psalm / IDE / whatever to flag it. If you don't habitually use these tools already, you're probably not going to be annotating your code with #[Override] anyway. My wager is the kind of people and teams who would be most interested in using and would benefit most from an #[Override] attribute are the kinds of people who are using static analysis tools and probably have configured PHPStorm / other IDE of choice to run those checks when a file changes, or via commit hook, or build pipeline, or whatever else. What I see here, then, is a perfect candidate for a userland attribute. Anyway, usual disclaimer applies; I'm not a voter on RFCs, I'm one man with an opinion, my opinion only matters insofar as gathering a range of community feedback matters to the author and interested members of internals. -Dave
