New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Methods named extension
cannot be invoked
#10076
Comments
We need to make Maybe we should make sure there is a space between the extension and the arguments in |
We only parse an extension clause must have a whitespace between the `extension` and the arguments.
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 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 |
@odersky is it decided that |
Yes, |
|
That one explains when
Since that's what's actually implemented, I think we can close the issue now. |
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.
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. |
Leaving my concerns aside, it should be still possible to parse I think as long as we make this work, we should be mostly fine with extension as a soft keyword. |
Previously, when discussing scala/scala3#10076 it was mentioned that `extension` would become a keyword, but turns out it will not be. I kind of jumped the gun here and we should not have chanegd it until it was in the compiler code.
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? |
Previously, when discussing scala/scala3#10076 it was mentioned that `extension` would become a keyword, but turns out it will not be. I kind of jumped the gun here and we should not have chanegd it until it was in the compiler code.
Previously, when discussing scala/scala3#10076 it was mentioned that `extension` would become a keyword, but turns out it will not be. I kind of jumped the gun here and we should not have chanegd it until it was in the compiler code.
Previously, when discussing scala/scala3#10076 it was mentioned that `extension` would become a keyword, but turns out it will not be. I kind of jumped the gun here and we should not have chanegd it until it was in the compiler code.
I don't understand why it's risky? It's clearly defined. If you want to use
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. |
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/ |
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. |
Previously, when discussing scala/scala3#10076 it was mentioned that `extension` would become a keyword, but turns out it will not be. I kind of jumped the gun here and we should not have chanegd it until it was in the compiler code.
Previously, when discussing scala/scala3#10076 it was mentioned that `extension` would become a keyword, but turns out it will not be. I kind of jumped the gun here and we should not have chanegd it until it was in the compiler code.
Previously, when discussing scala/scala3#10076 it was mentioned that `extension` would become a keyword, but turns out it will not be. I kind of jumped the gun here and we should not have chanegd it until it was in the compiler code.
Previously, when discussing scala/scala3#10076 it was mentioned that `extension` would become a keyword, but turns out it will not be. I kind of jumped the gun here and we should not have chanegd it until it was in the compiler code.
Previously, when discussing scala/scala3#10076 it was mentioned that `extension` would become a keyword, but turns out it will not be. I kind of jumped the gun here and we should not have chanegd it until it was in the compiler code.
Minimized code
This code doesn't compile:
Expectation
Either this compiles or we shouldn't be able to name the function
extension
The text was updated successfully, but these errors were encountered: