Skip to content

Replace : _* with * #11233

Closed
Closed
@odersky

Description

@odersky

As suggested by @lihaoyi in contributors I believe it is better to change the "splice" syntax for varargs from xs : _* to xs*.

Benefits

  • It aligns the syntax for vararg types like String* with vararg splices, which is what other languages do as well. E.g. Python or Kotlin would use prefix * for both.
  • It drops an obscure use of _.

Why now?

I propose to do this for 3.0, for two reasons:

  • It's a fairly basic topic that is likely to be explained in most tutorials at some point (although, curiously, ProgFun does not mention it). It would be a shame to have to declare a more complicated syntax now, and then throw away the books when a simpler one comes out.
  • Scala 3 did change pattern splices from xs @ _* to xs: _*. We should not change it twice in a row, so we should go directly from xs @ _* to xs*

Problems

The main problem is confusion with postfix operators. I believe that was the reason why this syntax was not considered from the start. But nowadays postfix operators are very much a legacy feature, and we will start to deprecate the language import soon. The new disambiguation would be that a final argument arg * ) is a vararg spice, not a postfix expression. You can still write arg.* or (arg *)).

Migration

I propose the following measures to ease migration:

  • Support both arg* and arg: _* (respectively arg @ _* in patterns) in 3.0, to allow cross compiles.
  • Treat arg* as a postfix operator under 3.0-migration in order not to change meaning, but issue a warning
  • Drop arg: _* in 3.1 and offer a rewrite to arg*

Going further

In some other issue (link welcome) it was suggested that we generalize splice operations so that they can also be for other arguments than the last one. That would be a separate issue that's orthogonal to the one here. And it would be for after 3.0 for sure.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions