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

Is long? an integer type? #670

Open
bzbarsky opened this issue Feb 28, 2019 · 3 comments · May be fixed by #747
Open

Is long? an integer type? #670

bzbarsky opened this issue Feb 28, 2019 · 3 comments · May be fixed by #747

Comments

@bzbarsky
Copy link
Collaborator

Per spec, looks like no. That means that [Clamp] long? should be an error, right? Is that the intent?

@domenic

@peria
Copy link
Contributor

peria commented Jul 11, 2019

Is there any rule of connection priority? As far as I understand, it's not clear [Clamp] long? should be interpreted as [Clamp] (long?) or ([Clamp] long)?.
IDL grammar defines it in [Clamp] (long?) format, but I think its interpretation does not need to follow the same rule with its grammar.

@bzbarsky
Copy link
Collaborator Author

Right, that is exactly what this issue is about. Per grammar, you end up with [Clamp] (long?) which as currently defined is an error. It may make more sense to treat that case as valid and apply the clamping to the long in that situation, but it needs spec changes to accomplish that.

@bzbarsky
Copy link
Collaborator Author

Note that some people are trying to use things like this in their spec IDL, and that fails in Gecko, because we implement the spec as currently written. It would be good to sort out exactly how this should work, so browsers don't end up creating incompatible spec extensions to handle this case... @domenic, could you please take a look, since you probably have the best idea of what the original goal here was?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants