Add conformance tests around type decaying - #530
Conversation
| } | ||
| } | ||
| } | ||
| deduced_type { |
There was a problem hiding this comment.
@jnthntatum I believe this is the desired outcome, let me know what you think
There was a problem hiding this comment.
It's debatable whether the value would be list(list(type(int))), only because the empty list should have a free type parameter that gloms into the very specific element type on the right
There was a problem hiding this comment.
That was pretty much the conundrum I had (list<list<type<int>>> is what go produces today). Here's how I went about thinking about this. I think the LHS addition is not so controversial:
LHS = ([] + [[type(1)]]) -> list<list<type<int>>>
The troublesome part comes next:
[[type([])]] -> list<list<type<list<dyn>>> (Due to type decaying)
(LHS) + [[type([])]] -> concatenating list<list<type<int>>> with list<list<type<list<dyn>>>
So the question becomes, how to compute the least upper bound of the inner elements:
list < list < type<int> ⊔ type<list<dyn>> > >
int and list are disjoint types, so int ⊔ list<dyn> = dyn. Substitute it back to the AST, the resulting type is list<list<type<dyn>>>.
This is also consistent with how the runtime would've evaluated to [ [type(int)], [type(list)] ]
2 participants
Note that these will currently fail in all stacks. They require a much more involved fix around joining types