You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now in SSA arrays are a subtype of slice. Handling type hierarchy in SSA & codegen makes passes on the code more complicated, so we've decided to remove it keeping type hierarchy in the frontend.
Happy Case
There is only the Slice type in the SSA and we keep track of the length for ACIR execution.
Alternatives Considered
Removing type hierarchy in the frontend (arrays would require an operator or a method call to be converted to slices). This could create worse devex.
Additional Context
No response
Would you like to submit a PR for this Issue?
No
Support Needs
No response
The text was updated successfully, but these errors were encountered:
I was going to re-open this because #1963 is only about changes to the type system not the SSA but maybe it does fix it in a way I haven't considered before. If functions were polymorphic over whether they took arrays or slices then we'd monomorphize a new version of the function for each. So there wouldn't be any functions after monomorphization that accepted both.
Problem
Right now in SSA arrays are a subtype of slice. Handling type hierarchy in SSA & codegen makes passes on the code more complicated, so we've decided to remove it keeping type hierarchy in the frontend.
Happy Case
There is only the Slice type in the SSA and we keep track of the length for ACIR execution.
Alternatives Considered
Removing type hierarchy in the frontend (arrays would require an operator or a method call to be converted to slices). This could create worse devex.
Additional Context
No response
Would you like to submit a PR for this Issue?
No
Support Needs
No response
The text was updated successfully, but these errors were encountered: