Mixed*TypeCoercion purpose

[AndrolGenhald]

Is it useful for these to be distinct from their non-Mixed counterparts?
Why are they called Mixed? They don't seem to have anything to do with the mixed type.
When are they supposed to be used? Just whenever coercion is used on an array's key or value? Why is this ArgumentTypeCoercion but this is MixedArgumentTypeCoercion? Wouldn't ArgumentTypeCoercion (or a new issue LessSpecificArgumentType) make more sense?

[orklah]

array-key is often considered as mixed by Psalm. For a lot of purpose, those two types are pretty similar.

In your example, you try to compare int to array-key, so Psalms tells you this is indeed a coercion.

I guess the reason the issue is different is to give more control to users. by default, Mixed coercions are lvl 1 errors while ArgumentTypeCoercion is level 3.

[AndrolGenhald]

Of course, I'd forgotten a lot of stuff is the way it is because we want to have issues with different error levels. The added complexity from that is what eventually made me give up the last time I tried to rewrite type comparisons. I think I can work around it without too much trouble this time, and open the door for a more specific issue for just array-key coercion in the future.

[orklah]

Yeah, but there is no good alternative. You can't just flood legacy project with mixed issue before they had time to fix undefined classes. My work project has already tens of thousands of errors, and I chose each issue type I want to keep by hand...

[AndrolGenhald]

Oh yeah, if you have old annotations like Foo[] it totally makes sense to have an easily suppressible issue for the array-key coercions. It's annoying because from a type system perspective the extra information that the coercion was for an array-key is unnecessary, but for a static analyzer that wants to simplify working on less-than-ideal code it's absolutely necessary.

[orklah]

Wait until you get to the part where you have to emit a different issue depending on whether the type comes from a docblock or not :D

[AndrolGenhald]

I'm trying to stay away from the code that emits issues for now and just implement the existing type comparators in terms of the new type comparison API. It's revealed what I believe are a few actual issues that I'll point out in a bit, working on cleaning it up a bit and putting together a draft pull request.