Problem with iterable in generics

[robotomarvin]

I have a problem with more complex combination of generics and iterable. As you can see in (https://phpstan.org/r/17191b70-7aa3-4c35-9e6e-d3c17a4a9598). Analysis is telling me Pipeline<iterable<InputA>,iterable<InputA>>::addAction() expects Action<iterable<InputA>, iterable<InputB>>, AToB given. but AToB is actually Action<iterable<InputA>, iterable<InputB>>

I achieved it to work is wrapping iterable into a generic wrapper (https://phpstan.org/r/1bf8ef90-ec41-41e6-8c8a-ad20efd7513b), but that does seem right to me. Is there something I don't understand about covariance and contravariance? How would I go about this?

[ondrejmirtes]

PHPStan with your original example https://phpstan.org/r/17191b70-7aa3-4c35-9e6e-d3c17a4a9598 reports:

• Template type TInput on class Action is not covariant. Learn more: https://phpstan.org/blog/whats-up-with-template-covariant
• Template type TOutput on class Action is not covariant. Learn more: https://phpstan.org/blog/whats-up-with-template-covariant

Does the linked article gives you the answer to your problem? Do you have any questions about the points in the article?

[robotomarvin]

I have read this article before submitting my question.

On the interface level there is no covariance, , maybe the problem is that even when AToB implements Action<iterable<InputA>, iterable<InputB>> it is actually returning more concrete type run: Generator<InputB> which is then used as input to next action. But the same problem happens when I use just Generators as type.

I would expect covariant check on the type of iterable, not the iterable itself as it is only going to be iterated and output will always hase same types.

[ondrejmirtes]

I'm gonna call up @jiripudil, our resident variance expert :) Thanks.

[jiripudil]

Well, applying (co|contra)variance to the Action's template types (https://phpstan.org/r/52a401e0-cad6-45f7-9c85-26b67a6c5c1e) does help, but it should work even with invariant templates.

This is not a variance issue per se. But there's something strange. I've debugged this and it seems that when the addAction method call check reaches here, $this and the resolved $ancestor differ in a tiny detail: their key type. While the expected type in $this is StrictMixedType, the type provided by $ancestor is just MixedType. Those two types are not equal, and therefore invariant TemplateTypeVariance rejects them.

@ondrejmirtes do you have an idea where this discrepancy comes from? I haven't dug deeper, in case you happen to know right away :)

[ondrejmirtes]

Oh, I know what this is. The problem is that RuleLevelHelper on level 9 transforms MixedType into StrictMixedType, both in accepting and accepted type: https://github.com/phpstan/phpstan-src/blob/cbfb23d8420420324396bffd9e1c096553c933b3/src/Rules/RuleLevelHelper.php#L57-L79

The problem is that MixedType in an ancestor class isn't. If the accepting type is GenericObjectType like Foo<mixed>, that mixed is going to be transformed.

But if the accepted type is ObjectType like Bar and class Bar has @extends Foo<mixed>, the transformation in RuleLevelHelper isn't going to transform.

Relevant code: https://github.com/phpstan/phpstan-src/blob/cbfb23d8420420324396bffd9e1c096553c933b3/src/Type/ObjectType.php#L1442-L1497