On 3 November 2023 13:15:59 GMT, Daniil Gentili <dan...@daniil.it> wrote: >Well, I was actually thinking of enabling these compile-time checks only if >preloading is enabled, to ensure the closed-world guarantee.
Doesn't that just take us back to the "generic types are only optionally checked" scenario you were trying to avoid? Right now, I suspect the use of preloading is actually *less* common than the use of offline static analysers. Unlike OpCache itself, it's not something you can just switch on for an existing code base: you've got to switch from rules for loading classes at runtime to generating a static preload list in advance. To be reliable for static analysis, that preload list would need to be *comprehensive*, defining every symbol up front, then making a second pass of cross-file analysis. That makes it look very much like a separate build step, rather than something integrated into the normal execution pipeline. I've said before that this might be the way PHP should go - a native "module" concept, with full pre-compilation - but it would be quite a radical change. Perhaps an alternative is to change the rules of when autoloading can be invoked, by allowing the preload script to recursively autoload every symbol it can identify, rather than waiting for the relevant code to be executed. I think this is how current offline static analysers work. That doesn't solve the "optional checks" problem, though, if preloading remains optional. We could produce an error if any generic/extended type was encountered without being preloaded, but that poses a dilemma for libraries: either don't use the new types, or impose a requirement for applications to use preloading. I'm not convinced there's an easy compromise here. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
