Jan Tvrdík

Also note that top-level parentheses always have no effect, i.e. `(Closure(): int|null)` will aways be identical to `Closure(): int|null`. It's the same as in math, `1` equals to `(1)` equals...

So the issue in how we print the type?

> And failing silently in case of not supported syntax. I don't understand. `(Closure(): int|null)|null` is supported and parsed well. What would you expect? It's parsed as `(((Closure(): int)|null)|null)` and...

Yes, that is correct, even though it can be confusing. What would you expect? Note that the parentheses here are useless. `(A|B)|C` is the same as `A|B|C` and also same...

> One is closure which returns int|string or null Based on what? Is that you wish? Again parsing `Closure(): int|string` as `(Closure(): int)|string` is not a bug. It's very much...

I would expect double quoted string to support the same escaping sequences as PHP. See https://github.com/nikic/PHP-Parser/blob/master/lib/PhpParser/Node/Scalar/String_.php#L71-L130

I don't know. The only thing I can think of is to compile the `{skipIf}` to sth like `$iterator->setFilter(fn($it) => $it === 3))`, so the iterator itself is aware of...

Very much looking forward to this. I did some initial testing and the main issue I encountered is, that it does not support "closure" variables, i.e. `$foo` would be reported...

Would it be possible to introduce some "Latte fully typed mode" which would change compilation of ```latte {block description, string $description}...{/block} ``` from ~~~php public function blockDescription(array $ʟ_args): void {...

> My point is that PHPStan should be able to check this I don't see an easy way to do this as long as templates are compiled independently of each...