Truthy isset($arr[$k]) should narrow $k

[staabm]

closes phpstan/phpstan#11716
closes phpstan/phpstan#8559

see https://www.php.net/manual/en/language.types.array.php

[staabm]

I am puzzled by the test and its expectations:

phpstan-src/tests/PHPStan/Rules/Variables/data/bug-10577.php

Lines 9 to 27 in cb8f910

	private const MAP = [
	'10' => 'Test1',
	'20' => 'Test2',
	];
	public function validate(string $value): void
	{
	$value = trim($value);
	if ($value === '') {
	throw new \RuntimeException();
	}
	$value = self::MAP[$value] ?? $value;
	assertType("'Test1'|'Test2'", self::MAP[$value]);
	// ...

I feel the assertion in this test is wrong, see https://3v4l.org/WD7OG
after this PR we now get a *ERROR* which is not better either though ;)

[staabm]

the more iterations I do on this thing, the more I feel I need a new Type method, e.g. Type->toIssetOffset()

[staabm]

memo to me: maybe take inspiration from array_key_exists:

phpstan-src/src/Type/Php/ArrayKeyExistsFunctionTypeSpecifyingExtension.php

Lines 61 to 93 in e8027e7

	if (!$keyType instanceof ConstantIntegerType
	&& !$keyType instanceof ConstantStringType
	&& !$arrayType->isIterableAtLeastOnce()->no()) {
	if ($context->true()) {
	$arrayKeyType = $arrayType->getIterableKeyType();
	if ($keyType->isString()->yes()) {
	$arrayKeyType = $arrayKeyType->toString();
	} elseif ($keyType->isString()->maybe()) {
	$arrayKeyType = TypeCombinator::union($arrayKeyType, $arrayKeyType->toString());
	}
	$specifiedTypes = $this->typeSpecifier->create(
	$key,
	$arrayKeyType,
	$context,
	$scope,
	);
	$arrayDimFetch = new ArrayDimFetch(
	$array,
	$key,
	);
	return $specifiedTypes->unionWith($this->typeSpecifier->create(
	$arrayDimFetch,
	$arrayType->getIterableValueType(),
	$context,
	$scope,
	))->setRootExpr(new Identical($arrayDimFetch, new ConstFetch(new Name('__PHPSTAN_FAUX_CONSTANT'))));
	}
	return new SpecifiedTypes();
	}

[staabm]

array_key_exists also needs improvements phpstan/phpstan#11724 :)

[mvorisek]

Not directly related, but I wonder if substraction should be further and always generalized if possible, mixed~type can be always generalized, ie. into string|int|float|bool|null here.

[staabm]

I don't think it would have a functional difference. or do you have something in mind which would improve?

[mvorisek]

Pure readability of the type.

[mvorisek]

mixed~(''|'a'|null)

[staabm]

I guess this comment went on the wrong line (or I have puhsed a change at the same time you did the comment) and therefore it does not make sense atm?

[mvorisek]

I see it on correct line, it is for falsy context:

    $arr = [0 => 0, 1 => 1, 2 => 2];
    if (isset($arr[$mixed])) {
    } else {
        // falsy context
    }

if $arr[$k] is set (and not null because of isset), then the consts types in truthy context can be substracted in the falsy context

[staabm]

This is sealed vs unsealed array territory. I would not do this until we have a clear separation of the 2 types

[mvorisek]

Really? If array specifies some non-optional keys, they must be present (in sealed and unsealed array) and can be substracted in the else branch, can't they?

[mvorisek]

https://3v4l.org/Rml9s - we need phpstan/phpstan#6963 or sadly float here