MoreSpecificImplementedParamType for subclass of an interface implementation

[ChristophWurst]

https://psalm.dev/r/33a0a9254b

^ This seems to be the minimal example of an issue I ran into today. It appears Psalm doesn't derive the typed Closure down to the subclass. Or like the type is erased for the subclass.

[psalm-github-bot]

I found these snippets:

https://psalm.dev/r/33a0a9254b

<?php

interface I {
    /**
     * @param Closure $c
     * @psalm-param Closure():string $c
     */
    public function foo(Closure $c): void;
}

class A implements I {
    public function foo(Closure $c): void {}
}

class B extends A {
    /**
     * @param Closure $c
     * @psalm-param Closure():string $c
     */
    public function foo(Closure $c): void {}
}

Psalm output (using commit 1cd10c3):

ERROR: MoreSpecificImplementedParamType - 20:33 - Argument 1 of B::foo has the more specific type 'Closure():string', expecting 'Closure' as defined by A::foo

[weirdan]

I'm not sure it's a bug. I specifies the parameter as Closure():string, then A widens that parameter to Closure (valid according to LSP) and then B narrows it back to Closure():string (invalid).

The question here is whether we expect the docblock to be inherited (leading to potential problems with multiple inheritance) or not.

[Arkemlar]

in my case everything is much simpler - typical case when implementing framework interface.
https://psalm.dev/r/605fa7a49b

Getting:

ERROR: [MoreSpecificImplementedParamType](https://psalm.dev/140) - 23:37 - Argument 1 of TaskNormalizer::normalize has the more specific type 'Task', expecting 'mixed' as defined by NormalizerInterface::normalize

[psalm-github-bot]

I found these snippets:

https://psalm.dev/r/605fa7a49b

<?php

class Task {
}

interface NormalizerInterface
{
    /**
     * Normalizes an object into a set of arrays/scalars.
     *
     * @param mixed       $object  Object to normalize
     * @param string|null $format  Format the normalization result will be encoded as
     * @param array       $context Context options for the normalizer
     *
     * @return array|string|int|float|bool|\ArrayObject|null \ArrayObject is used to make sure an empty object is encoded as an object not an array
     */
    public function normalize(mixed $object, string $format = null, array $context = []);
}

final class TaskNormalizer implements NormalizerInterface
{
    /** @param Task $object */
    public function normalize(mixed $object, string $format = null, array $context = []): array
    {
        return [];
    }
}

Psalm output (using commit 73ebe22):

ERROR: MoreSpecificImplementedParamType - 23:37 - Argument 1 of TaskNormalizer::normalize has the more specific type 'Task', expecting 'mixed' as defined by NormalizerInterface::normalize

[weirdan]

in my case everything is much simpler - typical case when implementing framework interface.

And Psalm rightfully complains in your case because a valid code like this:

function f(NormalizerInterface $normalizer): void {
   $normalizer->normalize(new stdClass);
}
f(new TaskNormalizer);

will likely not work as intended.

[Arkemlar]

will likely not work as intended.

It depends on what is expected. This interface is for normalizer realizations, one for Task class, another for DateTime, there are some for stdClass too. It is ok that in every case it will get different object and produce different result like array, string, etc - according to return type of interface method. Actually, it is behind Symfony Serializer system that ensures every normalizer get type it is designed for. It is so because interface defines supports() method to be implemented and it returns type. I cut out that method because it is not relevant to bug case.

[weirdan]

Adherence to LSP is expected. It is for that reason you can't narrow down the native parameter type (and Psalm doesn't allow it for docblocks either). If you need to narrow parameter types, as opposed to widening them, you need a generic interface. Psalm (as well as PHPStan) supports generic interfaces, and Symfony ecosystem is not shy to use them. If some component doesn't (yet?) use generics where it should, then it's the problem with that component, not Psalm.