Infer closure type from context

[fesor]

Let's say we have simple function

/**
 * @template T
 * @param T[] $items
 * @param Closure(T): bool
 * @return \Generator<int, T>
 */
function filter(array $items, \Closure $fn) {
  foreach ($items as $item) {
    if ($fn($item)) {
      yield $item;
    }
  }
}

Right now psalm is unable to infer types for closure from this declaration

/** @var Item[] $arr */
$filtered = filter($arr, function ($item) {
    return $item->enabled();
})

Parameter $item has no provided type, could not infer type

example:

https://getpsalm.org/r/1a8f1377b0

[muglug]

Psalm can’t currently infer closure types depending on how those closures are used.

Evaluation for function/method calls is:

1. arguments are evaluated in order
2. function arguments checked (to test whether params & args match) and templated params are gathered up for the given call
3. return type is generated for that method call, given the templated parameters

In your example it would possible to figure out the types in step 1, but not if the param order was swapped. In that scenario, there’d have to be another sweep to collect all templated types in args, and solve for x (or T, here)

[fesor]

@muglug could you provide example with swapped param order? I don't quite understand.

[muglug]

Sorry, let this one slip.

$gen = filter($collection, function ($item){
    return $item->check(13);    
});

could work because we'd identify that $collection is of type T[] which means T = Item, then know that the untyped param in function ($item) ... should be of type Item because it matches Closure(T) in the called function.

But reverse the parameters so the closure is the first arg, and Psalm wouldn't know what to do:

$gen = filter(function ($item){
    return $item->check(13);    
}, $collection);

Now $item is a mystery type, and we don't know what happens when we evaluate $item->check(13).

To solve this we'd have to do a second pass to resolve all templated types, and that's not massively ideal.

[muglug]

See reply here: #742 (comment) - I think they're the same issue, and I don't think it's fixable

[muglug]

It's not quite the same issue, actually. Going to reopen, sorry.

[muglug]

But nevertheless, after a bunch of thought, I don't think this is worth my effort to fix (beautiful as it would be)