-
-
Notifications
You must be signed in to change notification settings - Fork 932
Description
Feature request
There are two related issues:
Both of these issues are about what happens in TypeCombinator::reduceArrays(). If I change the implementation to simply return $constantArrays;, this code sample https://gist.github.com/ondrejmirtes/ec6341f86cfbb8445ac7c93dc1dfd357 is analysed in a second instead of a minute. And it means that constant arrays are collapsed differently too.
The problem is that TypeCombinator::reduceArrays() has exponential (or something like that, it's been a long time since my CS degree) difficulty based on the input size. We should make it more performant and we should also collapse the arrays differently so that #6469 works as expected.
My problem is that it's not obvious to me how the arrays should be collapsed in a union.
I'd expect array{A: int} and array{A: string} to be array{A: int|string} (there's no value in keeping them separate).
But I'd expect array{A: int, B: int} and array{A:string, B: string} to remain separate: array{A: int, B: int}|array{A:string, B: string}. Because A key has different types in both arrays, and there are more keys with different types too, it's valuable to keep them separate in order to enable tagged unions.
I'm not sure how to express this logic, and there are maybe some questionable edge cases too.
Anyone feels up to solving this? /cc-ing people who did similar work before: @rvanvelzen @arnaud-lb @JanTvrdik
Thanks :)