-
Notifications
You must be signed in to change notification settings - Fork 27
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
No need for NLTH with with
keyword
#136
Comments
I suppose we could, but why would that be an improvement? |
For the spirit of Non sunt multiplicanda entia sine necessitate, I suppose. Every NLTH should exist to solve actual ASI hazards. Furthermore, it's not hard to envision that some may want to format the statement as: import aRidiculouslyLoooongName
from "a-ridiculously-loooong-specifier"
with { type: "json" }; Aligning the three keywords has some kind of visual appeal. It's better if the language can refrain from imposing formatting restrictions if unnecessary. |
I have never seem someone splitting their import declarations like that, because usually multi-line imports are with named imports and thus the newline is before |
I don't think it has much sense, there is benefits in languages like Python, where everybody writes code in a similar way (and says that this is a big advantage), the same goes to:
which tries to unify syntax in some standard similar looking code. I agree with @nicolo-ribaudo nobody writes import x2 from 'y' with {
type: 'json',
}; In a typical way to dynamic imports: await import('y', {
with {
type: 'json'
}
}); And that's definitely enough, I'm sure that NLTH made intentionally in this case. |
What if you have a really long import specifier, such that the specifier by itself exceeds the print width? Being able to write it as import foooooooooooooooooooooooooo from
"baaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaar"
with { ... }; Would be nice. Of course that's me playing the devil's advocate, but I'm saying it shouldn't be the language to decide how to format users' code; we haven't done that and we shouldn't.
No it isn't. It's simply refactoring artifact from the |
I don't think that would be nice at all :-) but yes, I agree the language typically doesn't, unfortunately, make these kinds of stylistic calls. |
I will bring this up at the next TC39 meeting for consensus given the current stage-3-but-not-really-due-to-#137 status, but to be honest I expect this to be not controversial at all. |
This has been fixed in the ecma262 PR for the proposal: tc39/ecma262#3057 |
Just an aside -- while this change makes sense looking at I'd argue we should just keep the parsing the same for |
The current syntax still says:
NLTH was necessary to avoid ASI and compatibility issues with the
assert
contextual keyword. However,with
is already a keyword, and is unavailable in modules, so the following is always a syntax error currently:Is it possible to get rid of NLTH before
with
, because line terminators are already allowed beforefrom
?The text was updated successfully, but these errors were encountered: