Hi Ilija,
The optimizer, including type inference, is limited to the scope of
the current file (along with internal functions/classes). [...]
Preloading is the exception, where all preloaded files can assume not
to be changed after PHP has booted.
Well, I was actually thinking of enabling these compile-time checks only
if preloading is enabled, to ensure the closed-world guarantee.
We could make type checking a CLI step but how is that really better than
PHPStan or Psalm at that point
Yeah don't really like the idea of a separate "typechecking" step
either, I'd really love for this to be an integral part of the execution
process, not as a separate static analysis step.
PHPStan and Psalm are arguably successful *because* they are
written in PHP, making them much easier to maintain and contribute to.
Agreed, however if at least some static analysis functionality is
already implemented, I see no reason to not make use of it, even if
PHP does not accurately represent arrays in the optimizer and has no notion of
array shapes.
personally I really like array shapes but *only* as a stopgap measure
while switching to full object DTOs, so I'm comfortable with the idea of
not having static analysis for array shapes (actually, I would
absolutely love to just treat all array values as mixed during static
analysis, though array/list generics might be nice and easy to
implement...).
Another issue, specifically pertaining to generics, is that PHP has
type coercion. In both weak and strict typing mode, a float function
parameter will coerce an integer value. However, if generic types are
erased at runtime then the VM cannot do coercion for foo<float>($int)
(where function foo<T>(T $var)). This will require either accepting
inaccurate runtime types, or establishing stricter static rules that
do not match the existing behavior.
Well I'm all for stricter rules :)
Regards,
Daniil Gentili.
