Dotty: Methods named `extension` cannot be invoked

[tgodzik]

Minimized code

This code doesn't compile:

def extension(a : Int ) = 5 
extension(1) 

Expectation

Either this compiles or we shouldn't be able to name the function extension

[nicolasstucki]

extension is parsed as an extension clause.

We need to make followingIsExtension a bit smarter.
https://github.com/lampepfl/dotty/blob/3a52817bf06e1099a3bbf274fe6566760a56ecb4/compiler/src/dotty/tools/dotc/parsing/Parsers.scala#L918-L920

Maybe we should make sure there is a space between the extension and the arguments in extension (x: T) def ... for extension clauses. extension(x: T) def ... seem wrong. If that is the case the application would not be ambiguous.

[odersky]

What if the function is parameterless? What if it is meant to be called like this?

extension{1}

Or it might be intended to be used as an infix operator. In all of these cases extension would still be callable.

So I think it's best to leave it as it is. We want to have a simple criterion when extension is a keyword and that's that it is followed by (.

[tgodzik]

@odersky is it decided that extension will become a keyword? I will need to update it in the scalameta parser.

[nicolasstucki]

Yes, extension will be a keyword. It is the only possible way to make parsing unambiguous for this kind of syntax.

[tgodzik]

extension is still not a keyword and the issue is still not fixed. I order to properly support it in scalameta I need to be sure what the situation is. Please do let me know what is going on with this.

[odersky]

extension will stay as a soft keyword only. I have just updated the file on soft keywords in #10878:

https://github.com/lampepfl/dotty/pull/10878/files#diff-e6b4e879e6047adb52942d05da6e5900f1ffdcd705e8e044d5cd169e13532749

That one explains when extension is treated specially:

Otherwise, soft keywords are treated specially in the following situations:
... - extension, if it appears at the start of a statement and is followed by ( or [

Since that's what's actually implemented, I think we can close the issue now.

[tgodzik]

This seems incredibly risky, it's a very special case that everyone needs to be aware of and certainly not beginner friendly as we are striving Scala 3 to be. I imagine people being incredibly perplexed when their code doesn't work as it's supposed to.

Yes, extension will be a keyword. It is the only possible way to make parsing unambiguous for this kind of syntax.

Are we saying that this doesn't work and it's fine? Why would we not want to make it unambiguous ? What is the actual benefit of leaving it as a soft keyword? It will be able to break existing workspaces wanting to upgrade anyway.

[tgodzik]

Leaving my concerns aside, it should be still possible to parse extension(1) as a normal method invocation. No reason for this not to compile. Should be fine as long as someone doesn't add the type ascription there.

I think as long as we make this work, we should be mostly fine with extension as a soft keyword.

[tgodzik]

Are we going to do the same with https://github.com/lampepfl/dotty/issues/10374 ? Is this fine for a language to have hidden issues like this? I doubt that when learning the language anyone will take notice of the possible implications of this. Are we aware of any other languages that have soft keywords and how it impacted them?

[odersky]

This seems incredibly risky, it's a very special case that everyone needs to be aware of and certainly not beginner friendly as we are striving Scala 3 to be. I imagine people being incredibly perplexed when their code doesn't work as it's supposed to.

I don't understand why it's risky? It's clearly defined. If you want to use extension in that situation, put it in backticks. The possible alternatives are

• make extension a hard keyword, forcing everyone who uses extension as a field of a file or similar to put it in backticks, or
• make the disambiguation algorithm more refined, rendering the spec more complicated and the cases where it fails more obscure.

I think the current solution is quite acceptable as a middle way. And I don't really see that it would matter much, either way.

[odersky]

Are we going to do the same with #10374 ? Is this fine for a language to have hidden issues like this? I doubt that when learning the language anyone will take notice of the possible implications of this. Are we aware of any other languages that have soft keywords and how it impacted them?

Kotlin has a bunch of soft keywords, but I have not seen any reports how it impacted them.

EDIT: C# also has a large number of them. They call them "contextual keywords". https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/

[tgodzik]

I might have looked at it the other way around. I thought of soft keywords as identifiers that can sometimes becomes keywords, while it seems that they are rather keywords that can sometimes be used as identifiers. Might seem a small difference, but I think it might totally change the way people should be taught. In essence they should be made aware that those are keywords and they are not as safe as normal identifiers.

Sorry, if I am a bit too persistent about some of the syntax details, I am rather invested in making it all work well 😅. If there are indeed other languages that do this then my concerns might be totally unfounded.

Let's close it. I will fix the scalameta parser and if ever this becomes a problem, we can deal with it at the time.