You've opened the pull request against the latest branch 1.11.x. If your code is relevant on 1.10.x and you want it to be released sooner, please rebase your pull request and change its target to 1.10.x.

I don't trust Rector with downgrading switch to match, please rewrite the code manually 😊

I'd love to review this PR but please make the build green first - there are some failures in integration projects but everything in phpstan-src should be green. Thanks!

Ok, rewritten. From what I've skimmed through, all failures in phpstan-src were related to that match, so here's me hoping that everything turns green now 😊

Soo if I remember our conversation correctly, the idea is:

• @template T allows us to reference T in method parameters, but on the other hand we can't pass Collection<Dog> into Collection<Animal>
• @template-covariant T does not allow us to reference T in method parameters, but on the other hand we can pass Collection<Dog> into Collection<Animal>

The above points describe "declaration site variance".

Type projections are basically "call site variance", meaning:

• We want T in method parameters, meaning we have to write @template T.
• But we also want to pass Collection<Dog> into Collection<Animal>
• This can be safe if we don't call the method the method that has T in parameters
• So we can allow "call site covariance" - such typehinted object will not allow us to call the method that has T in parameters

Can you tell me if this PR allows me to do the second bullet list? And do you plan to send more PRs, and what they are gonna do?

Thank you :)

Sure :)

We want T in method parameters, meaning we have to write @template T.

Correct.

But we also want to pass Collection<Dog> into Collection<Animal>

To be more precise, we want to pass Collection<Dog> into Collection<covariant Animal>, or Collection<Animal> into Collection<contravariant Dog>, or any collection into Collection<*>.

/** @param Collection<covariant Animal> $collection */
function doSomething(Collection $collection): void
{
    // now this function accepts Collection<Dog>
    // at the cost of not being able to call $collection->add()
}

This PR allows – and tests – the first part ("now this function accepts Collection<Dog>").

And do you plan to send more PRs, and what they are gonna do?

I'm planning to send two more PRs:

• one with a set of Rules that make sure you don't use call-site variance incorrectly, such as in @extends, or trying to create a contravariant projection of a covariant template type;

• and another one implementing the actual restrictions that call-site variance imposes on the object (the "at the cost of not being able to call $collection->add()" part). However:

  This can be safe if we don't call the method the method that has T in parameters

  That's a valid way of looking at it, but one I find unnecessarily restrictive. I'd like to pursue a more benevolent direction – one that preserves type safety but doesn't tie the developer's hands too much. The idea is that when template types are resolved, the call-site variance should be taken into consideration (the TemplateTypeVarianceMap introduced in this PR will come in handy there) and change the resolved type into one of the template type's bounds.

  But more on that in the subsequent PR, I don't want to sidetrack the discussion in this one :)

I have the code more or less ready, so the PRs should come in quick succession. I just didn't want to overwhelm you like last time 😅

Decided to put this on 1.10.x :) So that it can be released sooner once finished.

Thank you!