-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Don't allow inherited names to shadow names defined in the outer scope #8617
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
Comments
Example: class C:
val x = 2
object a:
val x = 1
class D extends C:
println(x) Here we currently print
Importantly, I would flag it as an error only if |
This implements the additional rule for name resolution: It is an error if an identifier `x` is available as an inherited member in an inner scope and the same name `x` is defined in an outer scope, unless - the inherited member (has an overloaded alternative that) coincides with (an overloaded alternative of) the definition `x` - `x` is global, i.e. a member of a package.
What if they're split files? // C.scala
class C:
val x = 2 // a.scala
object a:
val x = 1
class D extends C:
println(x) Should Just for the record, I, personally, dislike differences in behaviour based on same-file vs split files (like for imports/scope, and the empty package iirc), but I wanted to mention it to avoid the differences being inconsistent. |
Fix #8617: Check that there is no inheritance/definition shadowing
To answer my own question, no it doesn't matter (which I think is inconsistent?):
|
See scala/bug#11921 (comment)
I think it's worth experimenting with a rule which says that an inherited member is not allowed to shadow a definition of the same name in an outer scope. Imports in outer scopes would be unaffected.
This could be a warning in 3.0 and an error in 3.1
The text was updated successfully, but these errors were encountered: