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
Path to Stage 4! #58
Comments
Congratulations on getting to Stage 2. 👍 |
Hey, need help on any of these? (I'm happy to try and contribute the test262 tests or amend the spec according to the consensus) |
I'm comfortable handling the spec, but the test262 tests would be most helpful. Be warned, though, they'll need to be extremely rigorous. |
My review is at #60 |
My feedback:
Maybe a table (code point, hex escape string) would solve both of my issues. |
For the second, I have no strong opinions about how to denote the characters; I can certainly inline the string. For the first, isn't that required, otherwise this proposal won't be able to produce output that works in both u and v mode? |
No, I believe hex escapes are sufficient for this purpose. Do you have a specific counterexample? |
cc @bakkot since this was a result of their research |
Hex encoding works, it just makes the output completely unreadable. I can't imagine we're going to make |
I do not value the readability of the output. This function is meant only for composing and then compiling RegExps. |
Sometimes you have to debug compiled regexps. |
You can decompile them and represent them however you like. Paste them into a visualiser. |
That's a bunch more work than doing |
@michaelficarra as far as the spec review goes, I've addressed your editorial comment; can I check you off? The normative one we can certainly discuss further if needed. |
The spec text is fine for what you intended. I still have issue with the escaping design though. |
Thanks! I'll check you off, but can you file a new issue to further discuss the escaping design? That seems like the only obstacle to seeking stage 3. |
Escaping using hex escapes also has the advantage that it's straightforwardly polyfillable in practice, whereas changing the UnicodeMode grammar would seem to not really be. |
My review:
The first issue is trivial to fix and the second is purely editorial, leaving only the third as something to actually resolve (potentially even by accepting the risk and making no normative change). In my opinion, this is ready for stage 3. |
First two are fixed; we can discuss the third in #66 but iirc the intention was simply to not support using the output of |
Spec draft is fairly short and I didn't see any glaring editorial issues. I find the alias definition for "the ASCII punctuators that need escaping" as a separate paragraph the precede the algorithmic steps strange. Why not have a step that says "Let the ASCII punctuators [...] be the String [...]"? |
Sure, I could do that - happy to go with whatever yall want there. |
ok, this has been reworked with #67 - @jridgewell @michaelficarra @gibson042 @syg @bakkot, can you confirm that you're signed off, assuming you are? |
LGTM |
1 similar comment
LGTM |
@bakkot Does the string coercion in step 1 align with our new coercion strategy? |
Oh, good point. This should throw a TypeError on any non-string inputs. |
ah, good catch. updated in 29b08c3 |
LGTM |
I see one normative issue and a handful of editorial issues:
|
Regarding the last item, I'm not sure optimizing for brevity helps readability here. Regarding item 4, I had "the ASCII punctuators that need escaping" as a dfn, but removed it after #60 (comment) and some editor feedback that a dfn wasn't needed. Will take a look at the item 1 issue (thanks!) and will fix item 2 soon. |
@ljharb The point about an unescaped delimiter ( |
Let punctuators be the string-concatenation of "(){}[]|,.?*+-^$=<>/#&!%:;@~'`", the code unit 0x0022 (QUOTATION MARK), and the code unit 0x005C (REVERSE SOLIDUS). |
ah ok, gotcha, thanks. |
k, that's landed in c95db79. |
Filxed #71 to handle the surrogate pair stuff. |
@gibson042 @syg latest changes are landed; can you confirm if/that you've signed off? |
Yep, that resolves the normative issues so works for me. I'll open PRs to demonstrate my editorial preferences. |
No advancement this meeting:
Once these are resolved, I'll return and re-ask for 2.7. |
@ljharb I imagine it means anything in |
Presumably also |
The other thing in |
You can't do |
I've been watching the progress on this repo for a long time now. I just want to say I appreciate the hard work and careful thought everyone has put into this (including the upcoming work as well.) It's been fascinating observing the concerns and challenges that the web environment raises for ECMAScript that were not much of a concern for other languages that have long had the same feature. I am wondering if the repo owner(s) would consider opening the GitHub Discussions tab in order to allow more back-and-forth discussion with fewer concerns about constantly pinging the people watching the Issues? I am sure if anything interesting distills out of Discussions, people will be more than happy to filter the info back into Issues (I don't think there is an expectation that the owners will monitor / reply to discussions, besides the unlikely chance that moderation is needed.) Just a thought. |
I'm not sure there's any way to disable issue notifications while enabling discussion notifications, and I think the same expectations exist for both about owner responsiveness. |
Stage 4
Stage 3
Stage 2.7
/u
flag vs./v
flag #55Stage 2Stage 1The text was updated successfully, but these errors were encountered: