> > > If one would actually use the highest possible level of the static > analysis tools they would need to “convince” the static analyzer that > “yes, unserialize() is actually returning an object of the right type”. > This is typically done with `assert($foo instanceof SomeClass);`,
> something that PHP will double-check for you at runtime. Interesting that you mention specifically assert, which PHP actually does **not** double-check for you at runtime, in production by default, so there is actually a precedent for a language feature that only does typechecking in the development stage. My > understanding based on the discussion is that the RFC specifically > excludes support for `instanceof SomeClass<SomeType>`, folks would need > to fall back to `/** @var … */` comments or mark the offending line as > ignored in some other way - which basically means that even *if* PHP > supported generic syntax, they would need those doc comments. While this could be a valid remark, in practice @var is considered harmful at least by Psalm, and overall I have never seen it used (with good reasons) in generic production code, simply because if your code needs to know the specific types of some generic bounds, you would have already specified them in parameter/property typehints (statically guaranteeing all consumers that require specific bound types are passed that bound); if not, there's no point in using @var at all, and you can just keep using the generic type (appropriately specifying it in returned types and other outputs). Kind regards, Daniil Gentili. > >
