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

[RFC 0118] Extra semicolon as a warning instead of an syntax error #118

Closed
wants to merge 2 commits into from

Conversation

lucasew
Copy link

@lucasew lucasew commented Dec 3, 2021

Local code flow can leave a semicolon at the end of the file and this should be a warning instead of an error.

Rendered

@lucasew lucasew changed the title [RFC 0115] Extra semicolon as a warning instead of an syntax error [RFC 0118] Extra semicolon as a warning instead of an syntax error Dec 3, 2021
@KAction
Copy link

KAction commented Dec 12, 2021

I oppose changing (complicating) the language for the sake of a bit easier programming. Also, it is slippery road, and can cause semicolon mess as in JavaScript (it has obscure rules when newline is interpreted as semicolon).

Any decent editor is capable of pre-save hooks, and something as simple as sed '$ s/;$// would solve the problem.

@Ericson2314
Copy link
Member

Yes semicolons are just used with attribute sets, let..in and with;. There is no general notion of a "statement".

@spacekookie spacekookie added status: open for nominations Open for shepherding team nominations and removed status: new labels Jan 26, 2022
@spacekookie
Copy link
Member

The RFC is open for shepherd nominations now

@lheckemann
Copy link
Member

Nominations are still open, if anyone would like to move this RFC forward this would be welcome.

@lheckemann
Copy link
Member

I nominate myself as a shepherd for this RFC (full disclosure: I'm not keen on this RFC passing, but aim to take the role of shepherd seriously and don't intend to "veto" or anything).

@edolstra
Copy link
Member

edolstra commented Apr 6, 2022

Since we only have one shepherd nomination at this time, we've decided to convert this RFC to draft status. If people are interested in shepherding, please let us know and we can un-draft it!

@edolstra edolstra added status: draft and removed status: open for nominations Open for shepherding team nominations labels Apr 6, 2022
Comment on lines +29 to +33
# Detailed design
[design]: #detailed-design

Allow an optional semicolon at the end of an expression raising a warning if it's provided.

Copy link
Member

@Profpatsch Profpatsch Apr 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a detailed design.

I would expect to get a good idea of how this will be implemented technically.

Note that I tried adding an optional semicolon to the parser a few years ago, but it was rejected because my implementation was naïve (just have a giant lookahead essentially). So I’d like to see a technical design here that is feasible.

=> 2+2
4
=> 2+2;
warning: extra semicolon at the end of the expression
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For files, it should also show which file is having the extra semicolon.

Comment on lines +67 to +69
There are no alternatives so far.

The impact of not doing this is not critic.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One alternative is changing the error from:

error: syntax error, unexpected ';', expecting end of file

to something like:

error: syntax error, unexpected ';', expecting end of file
Consider removing the ';' at the end of the file or expression.

       at «string»:1:4:

            1| 1+2;
             |    ^

That said, allowing people to write ;, but outputting a warning might cause warnings in places when the parser touches a file lazily. Potentially warning about extraneous ; in files that I didn't write myself.

@infinisil
Copy link
Member

I think this RFC should be closed since almost all people don't think this is a good idea.

@lheckemann
Copy link
Member

This RFC is being closed due to lack interest. If enough shepherds are found this issue can be reopened. If you don't have permission to reopen please open an issue for the NixOS RFC Steering Committee linking to this PR.

@lheckemann lheckemann closed this Jul 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
9 participants