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. >