Use an operator other than dot for extension function calls

Language Design
1

Would you consider using some operator other than dot (.) for extension function calls?

I agree that extension functions are syntactically cleaner than Java static methods, but the current dot operator does not distinguish between the static dispatch of extensions and the dynamic dispatch of members, which can lead to bugs.

When calling an extension function with an implicit receiver, the new extension operator would be required as a prefix.

I don’t care what operator you use, other than that it:

  • is short (preferably one character, maybe two)
  • is visually distinct from .
  • visually separates the receiver from the member

I imagine that you could support both dot and its replacement for a while, with dot marked as deprecated. After a suitable transition period, the dot syntax could be removed.

Given the legacy code that currently uses dot, I imagine that this is probably a non-starter, but I figured I’d request it anyway…

2

How so? The only bug I can think of as a result of this is when a class later implements a extension function. So let’s say you have an extension fun Foo.foo() ... and then later someone adds a new function to the class Foo with the same name. But that case is already handled by the compiler with a warning, so I don’t see where this leads to bugs.
Also there are some disadvantages to your proposal.

  • The caller needs to know what is an extension and what is not (this will make the kotlin std nearly unusable IMO)
  • In a conceptual way people don’t think about extensions in a different way than members so why treat them different?
  • As you said, a new syntax would not work with already existing code
3

I think the issue is that you think theres a difference and in java there is and kotlin there isn’t. For example the string kotlin class has 4 actual member function and a bunch of extension function. The idiomatic way I’ve seen is to follow this. You should only make member functions when necessary.

4

Actually, the difference exists in kotlin, too. Extension functions are statically dispatched, meaning you cannot polymorphically override them in a subclass. In order for the overriding method to be called, the static (compile-time) type needs to be the subclass. This is the difference to member functions, which are dynamically dispatched.

This might not be a big issue. But it can definitely confuse developers that try to override them. And here it could lead to a bug: if the static type is not the subtype, It would silently fail the developer’s intention.

What’s more, because of smart casts, this difference can get hidden from the developer. Definitely something to be aware of.

5

Not really. If you use the override keyword the compiler would return an error. If you for some reason forget the override keyword, yes it might lead to bugs, but this case is not important enough IMO to warrant such a change to the language.
It’s something you should be aware of, though. I just think that in some cases usability and functionality trumps safety and this is one of them.

6

I wholly agree that this potential source of confusion does not warrant a change. Personally I like the dot syntax.