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
Currently, most static type evaluation builtins take either a type argument or an argument, but the second case is unsound in that the expression is evaluated for its type but ultimately ignored. For example, the following code will never execute the expression because the call's result is supposed to evaluate to a constant with no place to put the expression:
vara: i32=0;if(isInteger(a=1)){// a is 0}// a is 0
I therefore propose to remove the second case. Or does anyone actually have to use the second case for a good reason, somewhere?
The text was updated successfully, but these errors were encountered:
Argument for using expressions in the macro: running AS code transpiled to Javascript can function like AS can. Downside, we lose type information about float VS integer etc
Currently, most static type evaluation builtins take either a type argument or an argument, but the second case is unsound in that the expression is evaluated for its type but ultimately ignored. For example, the following code will never execute the expression because the call's result is supposed to evaluate to a constant with no place to put the expression:
I therefore propose to remove the second case. Or does anyone actually have to use the second case for a good reason, somewhere?
The text was updated successfully, but these errors were encountered: