those wouldn't even be needed anymore I guess because this function is wrapped in a TypeTraverser already that deals with union types. the alternative would be to explicitly handle only the first constant array and array below instead of all of them. not sure what is simpler / reads better, in the end it might not matter much..

Okay.

@herndlm I also think that if (count($type->getConstantArrays()) > 0) {...} is no longer needed.

The question is how to do it differently. A condition like that has to stay to access only the first ConstantArray and get rid of the union for example. Or any other ideas?

Had a closer look. What about this?

        $maybeEmptyArray = [];
        if (count($type->getConstantArrays()) > 0) {
            $constantArray = $type->getConstantArrays()[0];
            if (
                $constantArray->isOptionalKey(0) &&
                $constantArray->getArraySize()->equals(IntegerRangeType::fromInterval(0, 1))
            ) {
                $maybeEmptyArray[] = $constantArray;
            }
        }

        return TypeCombinator::union(
            ...array_merge(
                $maybeEmptyArray,
                array_map(
                    function (ArrayType $arrayType): Type {
                        return $arrayType->setOffsetValueType(
                            $arrayType->getIterableKeyType(),
                            $this->getType($arrayType->getIterableValueType())
                        );
                    },
                    $type->getArrays()
                )
            )
        );

I don't think that it matters whether we use $type->getConstantArrays()[0] or foreach ($type->getConstantArrays() as $constantArray) {}

No, this fails for

/** @var 'foo'|array{foo?: true, bar: int} $union */
$union = null;
assertType('array{foo?: string, bar: string}|string', esc_sql($union));

with

-'array{foo?: string, bar: string}|string'
+'array{foo?: string|true, bar: int|string}|string'

got rid of the array_map and union

If it is a maybe type !yes means maybe or no,
no means no only.

Both are not a 100% correct I suppose, the maybe case might need another extra handling instead of just returning the input below. I'll check it later.

dealing with the maybe here is highly annoying, e.g. your proposed change would lead to a *NEVER* (mine to a '') when a maybe array like mixed or iterable is passed. both are wrong. and in both cases PHPStan should be complaining because esc_sql does not support those types via PHPDoc. Natively it does of course, I know..

And I can't even say what we would return with a mixed, I guess we could just bail out early and not handle and return the default type or smth like that

adapted, what do you think? should at least be simpler and less wrong now :)

Thought the same, but can't return null here because this is wrapped with the TypeTraverser:map() which doesn't allow returning null AFAIK

BTW just curious, your profile says Vienna but you seem yo be active very late until into the night. Are you still in Vienna? I'm from Austria and lived there too, missing it a bit from time to time..

I still live in Vienna. My activity time mainly depends on my day job and after work napping :-D. Vienna is a nice place to live. I would miss it too at least in late spring and summer.

And good old boss Viktor is in Budapest, the twin cities, right? :)
Anyway, shall we merge? :P

Also: sorry for calling you old Viktor

I am old.