Looks great to me. Also, big +1 on this being the last change to the language for 3.0.
4 Likes
In and of itself, I think this is a real improvement. It’s quite late, but provided the old syntax still works for the time being, and deprecation doesn’t begin until at least 3.1, I don’t see any problem with it.
1 Like
I think it makes the language slightly less regular but slightly more familiar to those coming from other languages. And it’s yet another change to handle.
I modestly dislike it for these reasons, but it’s not a big deal.
import foo.bar as baz is nice.
import foo.* is okay.
import foo.{bar as baz, *} is worse than what we’ve already got, because * doesn’t mean “every”, but rather “match that which hasn’t already been named” which is what _ is supposed to mean. Note that Rust has the same syntax, but if you write use std::cmp::{Ordering as O, *} you also import std::cmp::Ordering along with everything else in std::cmp because it really is a wildcard.
Example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=59a6c88eb2d5271deca4d9b69d21a6a9 (note…this also shows how Rust has rather pedantic f64 sorting, hence the need to talk about orderings).
For Scala,
import foo.* with bar as baz
would be fine, though.
Anyway, it doesn’t much matter, I don’t think. It’s a small part of the language and we can learn anything that small, and renaming is nicer. Leaving it as is is more comfortable and more regular. Fine either way.
4 Likes
This, x100.
When Scala 3.0 is released, I look forward to a long period of syntactic stability, and a significant period of time where the only changes to the language are backward compatible. Ideally, all of 3.x.
Updating tools and books and videos is a herculean undertaking. And we don’t want to do that right after Scala 3.0 is released. Whereas, any last minute changes to the language right now may understandably upset those looking forward to Scala 3, but as virtually no production code has been shipped on Scala 3 and tooling is still in varying states of disarray (very little works fully on Scala 3), it has comparatively little commercial impact.
Others equally well-informed may come to different conclusions, but my own subjective opinion is that now is the time to change syntax, if it’s going to change at all for the foreseeable future.
As for the proposed import syntax, I think it’s a notable improvement, though I’m not that concerned one way or the other.
6 Likes
If the choice is: make the *-import syntax change now, or not at all in the next decade, Im +1.
I think aligning with other languages is a win. Many, perhaps most, engineers need to be polyglots, and aligning with convention in other popular languages (esp. python) reduces the mental effort when jumping between languages.
1 Like
I’m in favor of the * wildcard change (I’d have to be, since I proposed it!) and am neutral on the as change.
I do think as does look nicer, and renaming with braces is certainly nice as well, but it’s balanced out by the churn it adds to the language. Overall a wash, and given how infrequent renaming-imports are in the code I work with it’s probably not a huge deal.
I will repeat though that we can’t keep this churn up forever. Scala3 is already supposed to be months into feature freeze, so the choices are either (1) we lock down now and begin rigorously polishing (both implementation and spec) in preparation for release (2) we postpone the release to allow more ideation and lock down later or (3) we ship a half-baked language with a bunch of poorly-thought-through last minute changes with problematic interactions and unforeseen consequences that we’re stuck with for the next decade.
Those are the paths that lie ahead whether we like it or not. While I’m neutral between (1) and (2), (3) is equally likely if we’re not careful, and is something we need to avoid at all costs.
17 Likes
What it upsetting (for me, at least) is not the changed per se, they might be good (they even are).
What is upsetting is not recognizing that such changes
1/ might also be in contradiction with scala 3 other goals, like “it’s not a different language than scala 2” and “there’s an ease migration path” and “the language get simpler and more regular” (and so, assessment/revision of these goals might be needed),
and 2/ they factually mean that we were not in feature freeze in the last months, and that more time will be needed to assess the new language balance - and accept that if the balance is not right, perhaps MUCH MORE TIME will be needed to adjust it, especially if that’s the “last scala syntax for the decade”.
And actually, @lihaoyi told it much better than me here: Meanings of underscore (including wildcard imports)
3 Likes
While change _ into * as wildcard seems reasonable, I don’t feel the same for => into as.
Even in the example above it feels odd, as _ doesn’t feel as discarding but rather assigning Channel to the _ as a placeholder. With => I was always reading Channel => _ as “Channel into void” 
.
1 Like
We decided to target the end of this week for the RC1 release of Scala 3.0. The change of imports will be part of it. Thank you to everyone who provided feedback!
12 Likes
Hello, I’m pretty sure it was talked about recently and/or that there is a place where it’s documented, but I can’t find it back, so anyone would mind to point me to what it the foreseen planning for scala 3 (RC, etc) ?
great news! I’m excited for both changes and the RC 
Great. From a modest dev perspective I’m thinking 3.0 is where “I’ll go through all the effort to learn the new version and migrate my code”. While not equal weight to “the books get rewritten” I do believe many in my position would rather this be a one-off bigger change.
Also, the new notation seems indeed an improvement and don’t anticipate headaches with it.
Kind of reminds me of my time in school. I would have files on my computer called thesis_final.pdf, thesis_final2.pdf, thesis_final3.pdf, thesis_REALLYfinal.pdf.
4 Likes
Use semver
1 Like
To indicate which versions of the thesis are compatible? 
2 Likes
Why does the issue of having to redo the MOOCs apply to changing optional braces but not to this change?
2 Likes
Why does the issue of having to redo the MOOCs apply to changing optional braces but not to this change?
I suspect it is either 1) MOOC material doesn’t have the imports or 2) changing _ to * and => to as doesn’t change layout; everything fits where it did before.
There’s a Russian saying:
“The church is nearby, but the roads are icy. The pub is far, but I will walk carefully.”
10 Likes
“There’s a X saying” on the internet that actually comes from the cited country. I did not expect that 
Source (TL;DR: they traced it back to a Russian language primary source from the 1890s)
3 Likes
Both imports and :/with require changes. Imports much less since there are fewer wildcard imports than classes. But we found a technical solution that could have replaced most uses of : with with without requiring a re-recording. So this was not the deciding factor to stick with :.