Array return types with template constraints

[ScopeyNZ]

Template constraints are supposed to let you constrain your templates to a known type, but it appears to have some unexpected results when it comes to arrays. Why is the inferred type of an empty array not covered by @template T as array?

For example, I get psalm errors with this code: https://psalm.dev/r/9aad57a7b1

Am I misunderstanding something?

[AndrolGenhald]

Am I misunderstanding something?

Yes. The type you are returning is array<never, never> (never is a special "impossible" type, so array<never, never> is the type of an empty array, ie the type of the items in the array is "impossible" because it has no items, but I digress). The type you've told Psalm you're going to return is PreparedData, which is a template. When you're returning a template, Psalm makes sure that the type you're returning is that template. Returning a type that satisfies the template constraint is not enough, because children may have tighter constraints on the template.

Consider: https://psalm.dev/r/8e61b8e52d. Bar is extending Foo with the template as non-empty-list<int>, so Bar::prepare() is supposed to return a non-empty-list<int>, but in your implementation it will incorrectly return array<never, never>, which is not a valid non-empty-list<int>.

[ScopeyNZ]

How am I supposed to say that the template extends an array which may or may not have elements? In that case, an empty array is entirely valid?

The whole idea here is that extensions of the abstract class may refine the template to a more specific array spec.

[ScopeyNZ]

I understand the error I'm being given, my original question is more around why is as array specifically not array<never, never> which seems to me that it's still an array, so should be covered.

[AndrolGenhald]

How am I supposed to say that the template extends an array which may or may not have elements? In that case, an empty array is entirely valid?

Returning an empty array is valid for the abstract class, but it might not be valid for subclasses, and those subclasses aren't forced to re-implement prepare(), so the implementation in the abstract class must be valid for all possible subclasses.

The whole idea here is that extensions of the abstract class may refine the template to a more specific array spec.

What if a subclass refines the type to a non-empty array, but doesn't reimplement prepare()?

I understand the error I'm being given, my original question is more around why is as array specifically not array<never, never> which seems to me that it's still an array, so should be covered.

array<never, never> is a subtype of array yes, but it's not a subtype of PreparedData. The template constraint is an upper bound on what types are acceptable, but not a lower bound, so PreparedData might be constrained further by a subclass to be something that array<never, never> is no longer a subtype of (like non-empty-list<int>).

[ScopeyNZ]

What if a subclass refines the type to a non-empty array, but doesn't reimplement prepare()?

I would've thought that this would give you an error - but a helpful one, as it's reminding you that you'd have to implement prepare for your subclass to be valid. I get the point though, that the parent should always be valid for subtypes...

So I guess the only way to do what I want is to include an interface? Like so: https://psalm.dev/r/1c5b668b54

[AndrolGenhald]

It depends a bit on what you're trying to do, maybe a larger example that's a bit more like your actual code would help. Typically with these sorts of things you have a property with the template type that you can use: https://psalm.dev/r/3d5ffc3edd, or maybe in this case it would just be better to make prepare() abstract: https://psalm.dev/r/ffdfb20c7e

I would've thought that this would give you an error - but a helpful one, as it's reminding you that you'd have to implement prepare for your subclass to be valid.

Psalm also aims to be useful for libraries, and I would consider this to be a bug if it were in a library. Unless a class is final it's generally assumed that there may be children that Psalm doesn't know about, so issues like these are shown in the parent class. If you want to require prepare() to be implemented by every subclass separately though, that's exactly what an abstract method is for.