The state of then


#21

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.


#22

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.


#23

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.


#24

I keep my opinion here: it causes work (even if spread out over 10 years) and confusion (newcomers) for very little (for me personally: no) benefit. The best restaurants have a small menu; I would not add more of “multiple ways to do one thing”.


#25

Just to concurre: having multiple ways to do the same thing with ONLY syntaxt variations (ie not semantic change whatsoever) is a BAD part of Scala, not a good one.
I don’t talk about Python or some other language with extremelly high, imposed regularity, but all other things being equal, I would much prefer to reduce the number of syntaxic variation in Scala that to increase it.


#26

Fully agreed with Lukas and François: there is a massive wake of papercuts following a syntax change. To me, it’s just not worth it tweaking small things. (And I have been in bitter disagreement with Martin on the spacing around the parens of if's condition for a decade now :grin: .)

tl;dr:

  • removing deprecated stuff / redundancy / sharp edges / confusion: :white_check_mark:
  • new features: :rocket:
  • syntax tweaks: :face_with_head_bandage:

#27

https://docs.scala-lang.org/style/control-structures.html

control structures should be written with a space following the defining keyword

if (foo) bar else baz // right!
if(foo) bar else baz // wrong!

#28

Some people prefer even

if ( foo ) bar else baz

especially when foo is more or less complex. This generally does not contradict with the main style guide (however, this is arguable).

This all is about what people like to see and how do they feel about syntax. And this is not a field of constructive discussion because some people like one way, some like another and some people do not like several variants for one thing, however other people do not mind. Someone must voluntary set the rules because such discussion cannot end in the community and whatever solution will leave a lot of disagreed.


#29

Thank you both for weighing in on this. I mostly wanted clarification around the situation, so I am happy to see various perspectives laid out.


#30

Or as they say on “The Good Place:”

We’re totally forked!


#31

Why introduce syntax that’ll change nothing?
many people are already lost with scala syntax. I’m also sometimes confused whether use curly brackets or not. More freedom in such trivial case is a bad idea, things should be as straightforward as possible.

All changes’ll stay with Us for very long time (hopefully). Each of them blocks future changes in some way. There is so many great ideas we can change in language but having 2 almost identical syntaxes probably won’t help anyone.


#32

Thank you for taking the time to say this. I completely agree. I feel this way for multiple reasons, but one of them is as someone who teaches Scala to students. More syntax damages the language and, IMO, gives ammunition to those who complain that Scala is hard/complex.