Hey Ilija,

On Tue, Jan 12, 2021, 17:35 Ilija Tovilo <tovilo.il...@gmail.com> wrote:

>
> Definitely disagree here. Your existing code will continue to work fine
> without changes.
>

Code written to deal with `array` in a generic way will no longer work when
invoked through code paths that produce object keys: this is a general
problem with widening types overall, and is a clear BC break.

This can be verified by expanding the `array-key` meta-type in tools like
`vimeo/psalm` to include `object`, then scanning for issues in existing
libraries. For example, on generic arrays it was safe to cast keys to
`string`, but that guarantee no longer holds true, and depends on
caller-side values, which will change with the new addition.

So yes, there needs to be a code migration/adaptation in a large number of
downstream infrastructural libraries.

Again: this is a common problem with widening types (function return types,
operator/constructs possible return types), and hence why I bring it up.

Whether the problem can be mitigated is what should be discussed, but the
problem is objectively there.

>

Reply via email to