Vincent Langlet

I saw multiples projects with the syntax https://phpstan.org/r/df1d060b-9f2b-4b86-a4b6-4d4acac29474 ``` @phpstan-type MyType = int ``` When adding the "comment-feature", - either it could still support alternative syntax (like the one with...

> We implemented such rule here: https://github.com/shipmonk-rnd/phpstan-rules?tab=readme-ov-file#forbidnotnormalizedtype > > > > But it does not yet check catch statements. I think it shouldnt be hard to add it. Do you...

I would say it's a consequence of https://github.com/phpstan/phpstan-src/pull/2199 cc @staabm Do you think it's possible to either - improve the way it's degraded, in my case all the values are...

I wonder if the current simplification shouldn't be considered as a bug when looking at this code https://phpstan.org/r/2e8efd6d-10c7-4b84-913f-54f5478a8eb8 @ondrejmirtes

On the other side, it works well with a static function https://phpstan.org/r/de0607c5-93f3-4e40-8ea8-342aa325580d, so PHPStan does not seems to simplify the array before comparing the value to the return type.

@ondrejmirtes if we put aside the "Use `@var` feature request", there is also a bug currently in the way the array value is resolved because in https://phpstan.org/r/59161360-6a46-4c82-9d98-b0a485463d03 the type ```...

> I think we should report Maybe should it be an option ? I'm not sure about the use case but you might want to expose phpstan-type in a library...

Hi @mvorisek @staabm, As a first easy step shouldn't we remove the FALSE return type from `preg_*` call if the regex is valid ? https://phpstan.org/r/a4de9bb6-e99d-438b-bcb1-17335d0b3608 Do you have in mind...

> The returned value can still be false even if the regex is valid. This has definitely been discussed somewhere on the issue tracker. There might even have been a...

Not sure if PHPStan should follow something imposed by Psalm 20 days before the major release without discussion when another syntax `strict-array` was preferred for months and would have avoid...