Syntactic sugar feature suggestion: emitting rewriting of current scope name

I have thought of a neat syntactic sugar feature I think is useful.

My thought is to add an operator (triple dots) which refers to the scope you’re in, as follows:

  • …(params) will be used for a recursive call, emitting the need to rewrite the procedure name. Plus, it makes it more noticable for human eyes.
  • …method(params) or …property to access the current class’s properties within it. I thoght it could be a good solution for static stuff, but Scala seems to not have built-in static definition.

The two can be distinguished, since the first case has parentheses right after the triple dots, while the second case isn’t.

As for backwards compatibility, since you can still use the long version, it won’t have any effect on existing code, and since currently it’s illegal to use it in the context seen here (triple dots may only be used right now inside function declaration, not in the body), it also won’t effect any past-written code.

What do you think about it? Do you think it can be useful for programmers?

1 Like

It could just be an artifact of the way I tend to write recursive functions, but for me recursive calls are almost always loop(...), so this would only be one character less


I’m not sure this would be a great idea. While it might be nice to have in case you change the name of your method/class and your IDE isn’t refactoring properly, it might be confusing and it’d make the syntax more irregular.

Also, for your second bullet point, if by “current class’s properties,” you mean this.x, this would only save 2 keystrokes (and would really cost 3 since you can just do x directly). If you’re talking about the companion object’s properties, I guess it might save you some keystrokes, but since the companion object is kinda separate from the class you’re writing the method in, it doesn’t really make sense for it to refer to a different scope (the object), rather than the scope you’re currently in (a class).

(minor nitpick: I think you meant “omitting”, not “emitting”?)


I don’t think this proposal is the right way to go about it, but I can see how it would be handy to have an easier way to refer to stuff in the companion object.

1 Like

it would be handy to have an easier way to refer to stuff in the companion object.

Maybe it could use $ symbold as it is already used as companion object suffix for class file and Java interop.

For example, this.$ could always refer to current class companion object. But it also could be achieved right now with import alias:

package test

class Test {
  import test.{Test => $}


object Test {
  val hello = "Hello World!"

Ultimately, what I am hearing is a desire to have a less boilerplate-oriented way to directly refer to the companion object for a specific class or trait. If so, I second this.

Without your example import, there exists a clear cognitive dissonance when attempting to read through a class (or trait) that refers to its companion object. The specific issue is the apply() method. I have to slow down my reading to distinguish between when using the class’s name as the constructor use case (which is invisibly invoking apply) versus referring to the companion object singleton.

Over the years, I have just gotten much faster at reading through this cognitive dissonance. And my own observation of others I have taught Scala, it messes with their reading/understanding speed, too. The implicit apply, as awesome as it is, creates the reading flow ambiguity.

A very clear distinction, like you have outlined (although I prefer a word like “compobj” over a symbol like “$” myself) would both remove the boilerplate per class and standardize the method of reference which should overcome this specific Scala wart.


Another thing that I’ve thought of, is that a self-reference operator can help easily solve the situation when you need to implement a recursive anonymous function, which has no elegant solution in Scala, and apparently in any language.