Skip to content
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

Add NaN and Infinity Literal Syntax #693

Closed
peblair opened this issue Jun 4, 2021 · 4 comments · Fixed by #1472
Closed

Add NaN and Infinity Literal Syntax #693

peblair opened this issue Jun 4, 2021 · 4 comments · Fixed by #1472
Assignees

Comments

@peblair
Copy link
Member

peblair commented Jun 4, 2021

See title. Open questions:

  • What syntax should we use?
  • Should they be F32 or F64? We should probably have both, since F32/F64 NaN comparisons may not work correctly (need to check)
  • Perhaps others
@cician
Copy link
Contributor

cician commented Jun 6, 2021

I think this is a duplicate of #360.

As a user I actually need to detect NaNs ind +/-infinite Numbers, but I think it needs to be done with functions like numberUtils.isNaN, which is for WASM primitives and not exposed.

@peblair
Copy link
Member Author

peblair commented Jun 6, 2021

@cician This is actually talking about the syntax, whereas #360 is referring to the constants. As for the isNaN and isFinite predicates, we should definitely add those. I think we should open a separate issue for that.

@peblair peblair changed the title Add NaN and Infinity Literals Add NaN and Infinity Literal Syntax Jun 6, 2021
@cician
Copy link
Contributor

cician commented Jun 6, 2021

OK, thank you. I've opened a separate issue.

@ospencer
Copy link
Member

What syntax should we use?

I vote for NaN and Infinity.

Should they be F32 or F64? We should probably have both, since F32/F64 NaN comparisons may not work correctly (need to check)

Great question. Float literals of the Number type default to f64s, so I say we remain consistent. I think questions of equality should probably be handled by the operators.

As a side note, I would probably just make coerceFloat32ToNumber promote to an f64 and then simplify the Number operations to only worry about f64s and avoid the equality issue altogether.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

4 participants