-
Notifications
You must be signed in to change notification settings - Fork 8
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
Multiline signature destructuring #45
Comments
This is one of those tricky spots that come from having no way to see beyond the current line at any given point, a limitation of SublimeText. At "({", there’s no way to tell if it’s an object literal, arguments with destructuring, or regular assignment destructuring. In this case it’s assumed object literal at the start and doesn’t recover nicely (even after the second line, it’d still be ambiguous, just less so). I should be able to tweak this to avoid the "invalid" scope, but unfortunately it will never be possible to actually highlight the arguments as such in a case like this :( |
That's interesting. So this is limited to arrows. There is (I think?) a problem case that can be addressed within this constraint whereby the first line contains a default assignment… |
That’s true, yep. There is some handling for similar cases already that tries to "recover", which is what we’ll need to introduce here. This one is complicated a bit extra because at that stage we can know it’s an object binding pattern, but not whether it’s function parameters or an assignment expression (not detectable until the fifth line). |
Oh I see… So there's a dilemma of erring on the side of caution (we can't tell that this is valid code) and trusting the author (param assignment indicates a signature, we'll assume you know what you're doing until proven otherwise)… Because if it is an object literal, leaving the syntax error to the last line will be totally misleading 🤔 |
Well, not quite that — I would say the current behavior is a bug / oversight. The
So even once we handle recovery here, |
@barneycarroll There’s now an escape route for recovering from ambiguity in this position. Although it will always get the first n lines scoped wrong, and it won’t know in a case like this that the binding pattern belongs to parameters, it now at least knows that if it sees an assignment, it should switch to interpreting the remainder as a binding pattern; and existing recovery logic already takes care of the arrow. |
New lines seem to break signature syntax highlighting:
The text was updated successfully, but these errors were encountered: