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
It would be really nice from a code perspective if we could do something like arr[1l] or arr[1ul]. This would require allowing us to override the array get syntax which I don't think we currently support from a type checking perspective. It might be worth looking into allowing this eventually though.
Possible Idea 1
Given hindley milner doesn't support union types in its inferencing algorithm we could maybe require you the user to specify the type allowing something like arr[t: Int32], this could maybe generate a different ast node with a different type signature, we could warn the user when they use something different.
Possible Idea 2
Another idea, that would need some work would be to treat [] get syntax as an operator this would allow for a lot of great options because it could be linked to a function with the signature (arr: Array<a>, index: Number) => a, we would need to figure out how you would define this function but it would let us use the standard use syntax to select which one were refering to. This might also have some interesting consequences surrounding generators which could be useful.
The text was updated successfully, but these errors were encountered:
It would be really nice from a code perspective if we could do something like
arr[1l]
orarr[1ul]
. This would require allowing us to override the array get syntax which I don't think we currently support from a type checking perspective. It might be worth looking into allowing this eventually though.Possible Idea 1
Given
hindley milner
doesn't support union types in its inferencing algorithm we could maybe require you the user to specify the type allowing something likearr[t: Int32]
, this could maybe generate a different ast node with a different type signature, we could warn the user when they use something different.Possible Idea 2
Another idea, that would need some work would be to treat
[]
get syntax as an operator this would allow for a lot of great options because it could be linked to a function with the signature(arr: Array<a>, index: Number) => a
, we would need to figure out how you would define this function but it would let us use the standarduse
syntax to select which one were refering to. This might also have some interesting consequences surrounding generators which could be useful.The text was updated successfully, but these errors were encountered: