array_is_list makes the type less specific.

[mj4444ru]

https://psalm.dev/r/ffab419792

The test1 function passes the test successfully.

Errors are generated for the test2 function because array_is_list turns the $arr type into a non-empty-list<array<array-key, string>|string>.

[psalm-github-bot]

I found these snippets:

https://psalm.dev/r/ffab419792

<?php

/**
 * @param array{0: string, 1: string[]} $arr
 */
function test1(array $arr): string {
    [$a0, $a1] = $arr;
    
    return $a0 . implode('', $a1);
}

/**
 * @param array{0: string, 1: string[]} $arr
 */
function test2(array $arr): string {
    if (!array_is_list($arr)) {
        throw new Exception();
    }
    
    [$a0, $a1] = $arr;
    
    return $a0 . implode('', $a1);
}

Psalm output (using commit 3a24488):

ERROR: PossiblyInvalidArgument - 22:30 - Argument 2 of implode expects array<array-key, null|object{__tostring()}|scalar>, possibly different type array<array-key, string>|string provided

ERROR: PossiblyInvalidOperand - 22:12 - Cannot concatenate with a array<array-key, string>|string

[AndrolGenhald]

I'm leaving this open as an enhancement, but your check in test2 is pointless. Destructuring works based on keys rather than order: https://3v4l.org/ZuKtg

Now that destructuring with keys is supported (since PHP 7.1, the same version the short [] destructuring syntax was introduced), normal destructuring is functionally identical to using numbered keys starting from 0.

[mj4444ru]

I'm leaving this open as an enhancement, but your check in test2 is pointless. Destructuring works based on keys rather than order: https://3v4l.org/ZuKtg

It seems meaningless to you, because you do not know the logic.

In this case, I have to make sure that the data passed from the external source has 3 elements with keys 0, 1, 2 in ascending order. I do it like this:

if (!array_is_list($arr) || count($arr) !== 3) {
    throw new InvalidFormatException();
}

[AndrolGenhald]

It seems meaningless to you, because you do not know the logic.

It is meaningless as given in the example, I was just trying to be helpful by pointing it out since it can be somewhat unintuitive. If you have other code where it's not meaningless that's fine, it is something that I think is worth improving in Psalm.

[orklah]

If I'm not mistaken, the fix should be here:

psalm/src/Psalm/Internal/Type/SimpleAssertionReconciler.php

Line 2042 in cf25363

$array_types[] = new TNonEmptyList($type->type_params[1]);

We're trying to reconcile array{0: string, 1: string[]} with list<mixed>, we retrieved the "GenericArrayType" (should look like array<0|1, string|string[]> I believe), then, we're creating a TNonEmptyList who'll be rendered as non-empty-list<string|string[]>. All that is correct, but we lost that we had 2 definitely set keys. TNonEmptyList has a $count property who should be set to 2 in that case.

[AndrolGenhald]

I actually went a step further to make this possible.

[psalm-github-bot]

I found these snippets:

https://psalm.dev/r/ec9a06bb45

<?php
/**
 * @param mixed $arr
 * @psalm-assert-if-true list $arr
 */
function is_list($arr): bool
{
    return is_array($arr) && array_is_list($arr);
}
/** @var array{0: int, 1: bool, 2: string} */
$list = [1, true, "string"];
assert(is_list($list));
function takesString(string $_str): void {}
takesString($list[2]);

Psalm output (using commit 3a24488):

INFO: PossiblyUndefinedIntArrayOffset - 14:13 - Possibly undefined array offset '2' is risky given expected type 'int'. Consider using isset beforehand.

ERROR: InvalidScalarArgument - 14:13 - Argument 1 of takesString expects string, bool|int|string provided