Convert array<V> phpdoc to array<array-key, V>

[mvorisek]

Feature request

I understand that very commonly array<V>, ie. array phpdoc /wo key type, very commonly represents list<V>, hovewer definitely not always.

This is a feature request to fix array<V> to array<array-key, V> phpdoc instead which is trully equivalent and non-risky, so it can be applied safely even for large codebases and improved gradually (ie. to list<V>, key type improved or left if any key is allowed).

related with #7796 - but a new fixer should be probably introduced to be named better (like PhpdocArrayWithoutKeyTypeFixer) and be non-risky, maybe #7812 can be made non-risky, as IMO it is non-risky, see unresolved #7812 (comment)

/cc @Wirone @kubawerlos @keradus

[Wirone]

I believe the risky flag can't be removed, as this was explicitly requested by @keradus to treat it as such. But definitely PhpdocArrayTypeFixer fits better for this case.

[mvorisek]

I believe the risky flag can't be removed, as this was explicitly requested by @keradus to treat it as such. But definitely PhpdocArrayTypeFixer fits better for this case.

@Wirone can you please prove with https://phpstan.org/try demo that the usecase you defend, ie. #7812 (comment), more precisely the Collection|V[] from https://phpstan.org/writing-php-code/phpdoc-types#iterables, behaves really differently than when written as Collection|array<array-key, V>? IMO phpstan converts V[] to array<V> immediately which is internally equivalent to array<array-key, V>. But I might be wrong. Maybe this is somehow different thanks to "some phpstan collection resolving extension"? In any case, the current risky reasoning is not clear to me.

[Wirone]

I didn't defend anything there, I even questioned the need of marking that fixer as risky. Just pointed that if we consider it as risky, then description should be better than it was at that point, pointing to the only difference known to me. Especially this part:

Collection implements Traversable so Collection|Foo[] is interpreted as a Collection object that iterates over Foo. The array part isn’t applied.

As a quick check, there's a difference between this (Cannot access offset 0 on Collection&iterable<Foo>.), and this (Cannot access offset 0 on array<Foo>|Collection.). I don't know if it has any serious implications when this fixer is applied, but since it may change the way how PHPStan interprets the type it may for example lead to different errors reported, so when someone has it in baseline file, it suddenly can fail with 2 new errors (one for ignored error not found during analysis, and second with the "new" error). Have in mind this is only my assumption. Riskiness is ambiguous here IMHO, one rabbi will say "yes" whereas other might say "no" 😉.

[mvorisek]

Thank you - you found the difference!

• https://phpstan.org/r/8db9e1e7-aeb4-45e8-a6e4-46d42eec6347 V[] is array<V>
• https://phpstan.org/r/d2377284-a9a2-4b31-811f-61d26ca0d93e Collection|Foo[] is Collection&iterable<Foo>
• https://phpstan.org/r/e3edf151-59d5-4482-9da5-5a9c0362240c Collection|array<Foo> is array<Foo>|Collection and no collection iterable type is inferred!

@kubawerlos the #7812 risky description should be improved:

-Risky when using ``T[]`` in union types.
+Risky when using ``T[]`` in union type with iterable type without generics explicitly defined like `Collection|T[]`.

and preferably with the link to this post or to the 3 cases/explanations above.