Skip to content

Remove expression variant from isInteger, isFloat etc. for consistency #531

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dcodeIO opened this issue Mar 8, 2019 · 2 comments · Fixed by #2157
Closed

Remove expression variant from isInteger, isFloat etc. for consistency #531

dcodeIO opened this issue Mar 8, 2019 · 2 comments · Fixed by #2157

Comments

@dcodeIO
Copy link
Member

dcodeIO commented Mar 8, 2019

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:

var a: 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?

@jtenner
Copy link
Contributor

jtenner commented Mar 8, 2019

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

@dcodeIO
Copy link
Member Author

dcodeIO commented Mar 8, 2019

Hmm. Well. The obvious alternative is to emit an error or a warning if the expression has side effects. Doesn't eliminate the unsoundness, though.

@dcodeIO dcodeIO changed the title isInteger, isFloat etc. inconsistency Remove expression variant from isInteger, isFloat etc. for consistency May 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants