Re: Question about adding !function_identifier

> > Yes, I think we are rapidly approaching the limit where to make the > language stricter, we need an official static analysis tool, like Hack has, > rather than trying to do everything at run-time. It might even be possible to build this into OpCache somehow, so that if > you pre-analyse your code, it will skip runtime checks that it can prove > will never fail (e.g. return type annotation on a function that always > returns literals). > The tricky part is that PHP is a highly dynamic language (...) Features like scalar type hints, return types, property type hints, and preloading (which makes the definition of a type-hinted class available at compile time), should definitely help towards skipping a lot of runtime checks! On Fri, 5 Apr 2019 at 11:37, Rowan Collins <rowan.collins@gmail.com> wrote: > On Fri, 5 Apr 2019 at 09:57, Robert Hickman <robehickman@gmail.com> wrote: > > > > > > > For instance: > > > > > > function foo(): type nothrow { > > > throw new SomethingException; > > > } > > > > Would it be possible to analyse the call graph at compile time > > (bytecode generation) and then trigger a fatal error? It wouldn't be > > possible for variable functions/methods though. A separate static > > analyser could do the same thing. > > > > > Yes, I think we are rapidly approaching the limit where to make the > language stricter, we need an official static analysis tool, like Hack has, > rather than trying to do everything at run-time. > > It might even be possible to build this into OpCache somehow, so that if > you pre-analyse your code, it will skip runtime checks that it can prove > will never fail (e.g. return type annotation on a function that always > returns literals). > > The tricky part is that PHP is a highly dynamic language, so there's a lot > of cases where the analysis can only return "maybe". My understanding is > that this is what a lot of the work on Hack is doing: creating a language > which looks a lot like PHP, but doesn't have as many ambiguous cases which > can't be analysed statically. > > Regards, > -- > Rowan Collins > [IMSoP] >