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

No need for NLTH with with keyword #136

Closed
Josh-Cena opened this issue Mar 27, 2023 · 9 comments
Closed

No need for NLTH with with keyword #136

Josh-Cena opened this issue Mar 27, 2023 · 9 comments

Comments

@Josh-Cena
Copy link

Josh-Cena commented Mar 27, 2023

The current syntax still says:

import ImportClause FromClause [no LineTerminator here] WithClause ;

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:

import foo from "foo"
with (something)

Is it possible to get rid of NLTH before with, because line terminators are already allowed before from?

@ljharb
Copy link
Member

ljharb commented Mar 28, 2023

I suppose we could, but why would that be an improvement?

@Josh-Cena
Copy link
Author

Josh-Cena commented Mar 28, 2023

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.

@nicolo-ribaudo
Copy link
Member

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 }. However, the language generally tries to avoid NLTH unless they are absolutely necessary, and in this case it doesn't solve any parsing ambiguity.

@coderaiser
Copy link

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 in a couple lines, and better to keep it one line. Anyways we already have a place to break line:

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.

@Josh-Cena
Copy link
Author

I agree with @nicolo-ribaudo nobody writes import in a couple lines

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.

I'm sure that NLTH made intentionally in this case.

No it isn't. It's simply refactoring artifact from the assert era.

@ljharb
Copy link
Member

ljharb commented Jun 4, 2023

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.

@nicolo-ribaudo
Copy link
Member

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.

@nicolo-ribaudo
Copy link
Member

This has been fixed in the ecma262 PR for the proposal: tc39/ecma262#3057

@mgaudet
Copy link

mgaudet commented Jun 28, 2023

Just an aside -- while this change makes sense looking at with, it is slightly irksome for implementations that will have to support both with and assert that they have different grammars.

I'd argue we should just keep the parsing the same for with and assert here to avoid having to special case parsing for implementers who will handle both.

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

No branches or pull requests

5 participants