You are right. This works in Dotty:
scala> if 1 > 0 then println("bar")
bar
scala> if 1 > 0 then {
println("foo")
}
foo
You are right. This works in Dotty:
scala> if 1 > 0 then println("bar")
bar
scala> if 1 > 0 then {
println("foo")
}
foo
My thought is to make it a reserved word, to keep Scala 2 more consistent with Dotty
I don’t really see how you can unanimously reject SIP-12 and then eventually add it anyway…
If you read the minutes:
http://docs.scala-lang.org/sips/minutes/2016-08-16-sip-10th-august-minutes.html#discussion-of-sip-12-uncluttering-scalas-syntax-for-control-structures
The original proposer[,] Martin Odersky[,] is not present
There would need to be a new SIP, or a champion willing to revive the older SIP based on new elements since the rejection.
In any case, I would still be against it, as it introduces a second way to write things for no good reason whatsoever (and I am a Delphi fan). The only reason that was supposed to justify it was the completely alternative syntax based on indentation that Martin came up with at some point. In that context it was necessary. But I am also against that indentation based syntax, for exactly the same reason.
Why was it added to Dotty without discussion?
Dotty’s parser is based on this 2013 commit (https://github.com/lampepfl/dotty/commit/214eb8b650a86d1708b1257f89f53840a121de62) that was written while SIP-12 was still alive.
So really, it should be removed from Dotty unless SIP-12 gets resurrected and approved?
It seems weird that the meeting was had without the proposer present.
In Scala there are so much things that can be written in several ways (and in Dotty there are even more), so such claim sounds weird; especially on such a minor chage.
I feel that both variants have its own niche.
Java-styled variant looks better when condition expression is short.
if (sc) expression1 else expression2
ML-styled expression looks much better when condition expression is large or when it ends with a lot of parentheses. One more paren from if
does not add any clarity, thus then
variant looks better.
if foo.bar.what(ever, (tupled, f(g(5)))) then 0 else expr2
I’m personally in favour of keeping this form.
The opposition, as I recall, was that it was too big a change to just add to the language, and that it would cause real problems for cross-compilation.
But… We’re talking dotty here, a.k.a scala 3.0, where a lot of other big changes that wouldn’t play nicely with cross-compilation are also happening. If the change is going to be introduced then that’s the right time to do it!
Syntactically, it enables a more literate style of programming, and removes the inconsistency where conditionals need parentheses when following if
, but not in a pattern match. Both of these are desirable properties.
I hope “standard” scala steps up to support Beauty, Truth and the Good in syntax.
I guess Beauty happens at parser, Truth at typer and the Good at erasure.
You said it. This is about beauty. It also makes it difficult to have discussions around this topic.
Here are other languages without of parenthesis around if
statements. Note that not all languages provide conditional expression with if
, but we can see that parenthesis-less if
syntax beyond the functional ML family of languages.
IF HUNGER > 0 THEN
PRINT "Let them eat brioche"
END IF
if 0 == n:
print('no hits')
else:
print(str(n) + ' hits')
if n == 0
puts "no hits"
else
puts "#{n} hits"
end
if i > 0 {
n = 1
} else {
n = -1
}
if i > 0 {
n = 1
} else {
n = -1
}
if x < 0 then
printfn "neg"
else
printfn "non-neg"
Changes in Dotty are not subject to SIPs, SIPs only cover Scala 2. Dotty is still going through some phase of experimentation of how to do things better, so it’s only reasonable that every change doesn’t require acceptance from a strict review process.
Before the meeting, I had a discussion with Martin in which he was in favor of rejecting the SIP and rethink the changes in the future. That being said, there have been several cases in which the meetings have taken place without the proposer present; there is no clause in our SIP specification that prevents this from happening. So long as there is a quorum, the meeting takes place.
I support making then
a reserved keyword in Scala-2.12. The parentheses-less version of if
is already present in pattern guards, so this is not totally inconsistent.
So we have if no_parens
for pattern guards, if (parens)
and if no_parens then
. Too much confusion for me.
sorry to bikeshed, but I’d also like no parens on if, so I’d like to keep dotty’s approach and even see it in 2.13
Replacing if-plus-parentheses with if-then makes conditional syntax
inconsistent with while loops and for loops. Sorry, I meant to say for
comprehensions.
Those languages that have if-then usually have while-do and for-do or
equivalent.
If you are so much pained by the inconsistencies of if conditionals with
parentheses and match guards without, just add parentheses to your match
guards and it will all look consistent.
Dotty / Scala 3 was so far not fully subject to the SIP process, although it tries to track SIPs in its implementation (last one is SIP 35) and has proposed SIPs on its own (e.g. trait parameters).
As its definition solidifies that will probably change in the future. Regarding then
, we have much more freedom to introduce this in Dotty because we assume existence of a rewrite tool. Without such a rewrite tool, migration is more complicated. That’s why I did not want to pursue this further in the Scala 2 context and was happy to close SIP 12.
That said, and in view of LPTK’s comment in the corresponding Reddit thread https://www.reddit.com/r/scala/comments/80rb2u/the_state_of_then_by_eed3si9n/
I would be in favor of deprecating do-while now, because it would make the syntax more regular and would make migration easier.
It’s tempting to see Scala 3 as the possibility to introduce breaking changes. But every breaking change adds to the upgrade cost (*), which we should try hard to minimize. IMO the benefit/cost ratio is low here, we should spend the available budget on important issues.
(*) The cost of implementing the change and the rewrite tool rule are small. Asking everyone to do the change in their code is already more costly. And then we cannot run a rewrite tool across old documentation, unmaintained example code, StackOverflow, books.
Dotty seems to allow both Java/C parenthesis style and if-then style.
If it promised that current style will not be deprecated for another decade, would that make it a softer landing?
It does increase the surface area of the language, but compared to recent SIPs that are being considered/added, having if
sugar has almost no worries about actually breaking the semantics of the existing code.