-
Notifications
You must be signed in to change notification settings - Fork 26
2017-01 meeting summary #61
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
Conversation
This proposal advanced to stage 1 with overwhelming support from the committee given it's usefulness. That said, there is substantial concern about the behavior of this | ||
operator in several edge cases. This is a common complexity when adding syntax to a language. | ||
|
||
### RegExp Lookbehind |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lookbehind got stage 2 in November - Named Capture Groups is the one that hit stage 2 this meeting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GAH! We talked about both :-) Thank you, will fix.
reports/TC39/2017-01.md
Outdated
|
||
There is a feeling on the committee that it may be better to implement a bigint type - that is to say a type that is not limited to 64 bits, and can be optimized | ||
to the appropriate size based on the code, variables, and underlying system as appropriate. However, this presents more work in specification. If anybody has specific | ||
arguments about why a bigint type would be strongly preferable to an int64 type, we would be interested to hear your argument. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It wasn't clear after discussion that it would be more work - BE is going to investigate whether speccing BigInt is feasible in his time budget.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's phrased wrong. I agree.
reports/TC39/2017-01.md
Outdated
|
||
In addition, if you want to contribute your opinions, remember that TC39 discusses proposals on [GitHub](https://github.com/tc39) where you are welcome to have a voice. | ||
|
||
Finally, you can contribute code! TC39 maintains a test suite called [test262](https://github.com/tc39/test262) that validates conformance of implementations to the spec. They would love more help to get further test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/validates conformance of implementations to the spec/provides specs features acceptance/
The specs are just a recommendation, with it, TC39 does not require specific conformance. The difference is subtle.
Don't merge - needs review. @kborchers and @bterlson given I am a first-timer I"m sure I botched something here. Can I get a review?
Also, this is a draft and I'm sure there are grammatical errors, but I'm going to go eat dinner now.