Meanings of underscore (including wildcard imports)

Language Design
21

And yet we’ve deprecated and removed:

  • procedure syntax
  • do..while
  • symbol literals

to name just the few that I am convinced are in every Scala 2 book.

4 Likes
22

I think that I agree with @lihaoyi. It is important to draw a line, and I would say that we shouldn’t introduce any new features into Scala 3.

But I do also think that it is really important to make sure that the features and new syntax that has been added/introduced work really well together, and to try and remove as many warts now as possible. Particularly, if the plan is to disallow breaking changes after this.

I know that many of the key contributors have been putting in a huge amount of effort to achieve this, but it would be a shame if Scala 3.0 was released a little bit early with some syntax annoyances that could have been fixed. E.g., it is not really clear to me that everyone is convinced that the indentation discussion has necessarily reached the right place.

So, I support reasonable syntax changes for Scala 3 that make the language more consistent with itself (or other languages).

I would really like to see an extended stable beta release of Scala 3 with libraries with many of the libraries ported or compatible. This would allow a wider group of folks to play with the new version of the language, provide feedback, and make sure that everything is right.

1 Like
23

When to release is a difficult tradeoff. Nobody is ready to put a lot of work into something that will be released a year from now. The Scala Center and the community have done a carefully synchronized ramp-up to the release date. The initially foreseen release date has slipped by 6 weeks now since some constructs (mostly, meta-programming) were still in flux and since library authors felt they needed more time to test their ports. It might slip another 6 weeks; we’ll decide that next week. But that should be as far as it goes.

1 Like
24

Of course! Scala 3 is when the books are rewritten (and the MOOCs are re-recorded). That’s something you can do maybe once in a decade.

2 Likes
25

It’s worth pointing out that @lihaoyi’s suggested plan for 2021 is exactly what we have done … in 2020! We have been through all this, a year ago. Since December we were supposed to be in the “it’s freezed” mode. The last language changes were supposed to be introduced 6-12 months ago, not yesterday.

7 Likes
26

The ‘_’ character is a source of joke about scala, so IMHO: it is a very good improvement.

27

This is something I would like to avoid, but my computer algebra project currently relies on operator imports. Here is an example with +. So please can we avoid this.

28

But your project in the community build does not contain an import of *! Nor does any other project in the community build, with more than 1M lines of code inspected. So yes, it’s a theoretical possibility but it does not seem to be very common in practice.

2 Likes
29

The case with + above is perfectly symmetrical. I will need to import * (or change my design in a yet unknown way).

30

Using backticks to import * seems like an OK approach though? I have to reference or import things with backticks all the time (e.g. all the Java fields and methods called .type…) and it’s not really any less convenient than non-backticked imports

5 Likes
31

Problem is, it’s the user facing interface, so the simpler the better. It’s even meant to be an interactive, scripted interface. In fact, import is already to much in this respect, so I suppose I will have to rework my design anyway.

32

I like the proposed syntax, but I think this change isn’t actually helpful. It won’t help people who know Scala, and newcomers will have to contend with both syntax because they’ll likely be seeing Scala 2 codebases for a long, long time. In fact, it will be worse for newcomers because they’ll have to learn both.

So where’s the benefit?

3 Likes
33

I agree with Seb: this ought to wait until after 3.0. The 3.x series has a long future ahead of it and the language will keep changing. New syntaxes will be phased in, old ones will be phased out. Books will be revised. Confused newbies will come to Scala chat rooms and we’ll ask them “are you using version n, n + 1, or n + 2?” and get them straightened out. It’s the circle of life.

Haoyi’s proposal is at least realistic about how much further schedule slippage will result if a stopping point isn’t declared, and by that, I mean a stopping point that has already been reached.

6 Likes
34

It’s really common in our codebase, and I will try to guess it’s common everywhere where builder with proper self type is needed. With current version of Scala it require quite some ugly code/hacks to make it work with inheritance e.g.:

trait RequestBase[F[_]] { self =>
  type Self >: this.type <: RequestBase[F] { type Self = self.Self }

  def query(key: String, value: String): Self

  def query(key: String, values: Set[String]): Self =
    values.foldLeft(self)(_.query(key, _)).asInstanceOf[Self]

  def query(key: String, value: Option[String]): Self =
    value.fold(self)(query(key, _)).asInstanceOf[Self]
}

trait Request[F[_]] extends RequestBase[F] { self =>
  type Self >: this.type <: Request[F] { type Self = self.Self }

  def followRedirects: Self =
    query("x-follow-redirects", "1")
}

It would be great if it could be addressed in future releases

2 Likes
35

I’d really like to see * and as work in imports, especially if this is seen as the last opportunity for it. However, it’s time to meet a deadline and let Scala 3.0 into the world.

Maybe hand it off to someone familiar with that part of the code, and treat the deadline as a strict go/no-go. If the feature misses the train when it leaves the station then this feature gets left behind - to catch up later.

It wouldn’t be the worst thing to have only _ and => in Scala 3. * and as are perfectly clear, well-separated from the rest of the code, easy to tweak later compared to all the other improvements.

So many Scala examples cruelly skip the imports that maybe it isn’t so bad to do later.

1 Like
36

While I think it’s rather late in the game for 3.0, I’m sympathetic to replacing _ with *. In practice, even after eight years of full-time Scala, I still pronounce it as “star” in that position, because that’s what I’m used to from other languages.

4 Likes
37

[quote=“odersky, post:20, topic:4843, full:true”]

  1. Self types
    […]. So instead of
    trait T:
  this: U =>
  ...
    we’d write
    trait T:
  type This <: U
  ...

A suggestion – at the cost of a new soft keyword self (similar to lazy modifier), we could get intent-ful code, more power/expressiveness, avoid backward incompatibility and we’d get to chose the identifier of the self type:

trait T[U]:
   self type This <: Foo >: Bar[U]
  ...
38

I think it’s too late for this kind of change. It’s not even the worst of the _ weirdnesses that remain (the others are just harder to fix).

Also, with imports as they are, _ works as “blank, or fill in the blank”. In imports, filling in the blank means “yeah, everything, or at least everything else” in the otherwise weird foo.{x => y, _} syntax. That second _ certainly isn’t an “everything” or the previous rename wouldn’t work.

If you remove it, I think, ironically, it actually makes the rest of the usages of _ less regular because it’s not so obvious that it’s “fill in the blank” any longer; it seems more like “whatever”, which seems more singular. But then f(x, _) doesn’t fit.

_* is super-weird. That’s the one to fix. Imports already work fine. Changing to * would make things agree with other languages better, but it actually makes the language less regular because * is a perfectly valid import. import maths.{+, -, *, /} is perfectly okay now. Wouldn’t be with this change. _ isn’t a problem because you can’t name an identifier _ without backticks anyway.

So, my preference is to leave it alone. In a comprehensive redesign I’d probably change it, but it’s too late for a comprehensive redesign of more stuff, and it’s bad for backwards compatibility. And the status quo is pretty okay, I think.

10 Likes
39

Just wanted to say, as someone who is (arguably) pretty good with Scala, but never read any books or took any MOOCs about it: could it be that we’re a little too worried about these things? Printed books on anything technology-related can almost universally be expected to be obsolete within 12 months; online books and MOOCs can be updated in real-time as the language changes.

Trying to rush another 100kg of perfection into the language after slowly gathering 50kg of perfection into it over the last N years, seems like a recipe for mistakes that the 3.x series will have to work around. I think it’s more prudent to freeze it (like was supposed to happen quite a while ago) and test the heck out of it, and then just call it 3.0. If books and MOOCs are the reason not to do that, then I think those priorities are out of wack (IMHO)

6 Likes
40

Also FWIW I think the current RC has way more fundamental problems than syntax. It needs to be tested and proved reliable, and the things that 2.x offers but 3.x never got to (like specialization) ought to be addressed if anyone is expected to migrate. The forest has limitless things to work on, but the trees are why people will use Scala 3.

1 Like