-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Make then
optional at line end
#7276
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
Conversation
Also auto-indent after `if ...` as long as it doesn't match `if ... then ...` in anticipation of scala#7276 Also use lazy matching (`.*?` instead of `.*`) when possible to avoid backtracking explosion.
- do not auto-indent after end marker (fixes scala#7274) - auto-indent after `if ...` as long as it doesn't match `if ... then ...` in anticipation of scala#7276 - use lazy matching (`.*?` instead of `.*`) when possible to avoid backtracking explosion.
d431149
to
d834abe
Compare
- do not auto-indent after end marker (fixes scala#7274) - auto-indent after `if ...` as long as it doesn't match `if ... then ...` in anticipation of scala#7276 - use lazy matching (`.*?` instead of `.*`) when possible to avoid backtracking explosion.
`then` is treated like `;`: It is inferred at the end of a line, if - a new line would otherwise be inferred - the next line is indented Disambiguation with Scala-2 syntax is as follows: The question is whether to classify if (A) B C as a condition A followed by a statement B (old-style), or as a condition (A) B followed by a then part C, and an inferred `then` in-between (new-style) (new-style) is chosen if B cannot start a statement, or starts with a leading infix operator. Otherwise put, (new-style) is chosen if in ``` (A) B ``` no newline would be inserted. (old-style) is chosen otherwise. This means that some otherwise legal conditions still need a `then` at the end of a line. If (old-style) is eventually deprecated and removed, we can drop this restriction.
`do` can start an expression or a statement only under -language:Scala2. Maintaining this distinction is important in order not to insert spurious newlines in front of `do` in a `while` or `for`.
Issue "too far to the right" errors also at toplevel. Previously this was done only inside braces.
- Update current reference docs to what's implemented in 0.19. - Add links to new pages describing what will come in 0.20.
d834abe
to
912c672
Compare
test performance please |
performance test scheduled: 6 job(s) in queue, 1 running. |
Performance test finished successfully: Visit http://dotty-bench.epfl.ch/7276/ to see the changes. Benchmarks is based on merging with master (0d34bfb) |
title: New Control Syntax | ||
--- | ||
|
||
Scala 3 has a new "quiet" syntax for control expressions that does not rely in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/in/on
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Regarding the indented syntax, currently the following program checks without problem:
def test = {
var x = 10
while x < 10 do
x+=1
if x < 10 then
x+=1
}
I assume it's out of the scope of the current PR.
newLineOpt() | ||
val newSyntax = toBeContinued(altToken) | ||
if newSyntax then | ||
t = inSepRegion(LBRACE, RBRACE) { | ||
expr1Rest(postfixExprRest(simpleExprRest(t)), Location.ElseWhere) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: the name newSyntax
is not informative nor accurate.
Yes, and that's as specified. |
No description provided.