Skip to content
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

[SR-1687] Swift does not warn about shadowing #44296

Open
swift-ci opened this issue Jun 5, 2016 · 4 comments
Open

[SR-1687] Swift does not warn about shadowing #44296

swift-ci opened this issue Jun 5, 2016 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself feature A feature request or implementation

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Jun 5, 2016

Previous ID SR-1687
Radar rdar://problem/18258863
Original Reporter May (JIRA User)
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, LanguageFeatureRequest
Assignee None
Priority Medium

md5: 3393657e7a6fab4aa1fc1b329a47aa67

is duplicated by:

  • SR-3496 Silent parameter shadowing is a source of subtle, hard to spot bugs

relates to:

  • SR-214 Swift 2: Guard let can shadow func param but not let-bound local constant
  • SR-11078 Property and class can't share names.
  • SR-5916 Assigning to var from func of same prefix throws compiler error
  • SR-4174 Compiler should emit warning when shadowing bound variable during pattern matching
  • SR-4811 Type's name can be assigned a value
  • SR-6613 Warn when shadowing an instance variable with a local variable
  • SR-8524 Shadowing in protocols leads to difficult to find bugs
  • SR-9096 If a variable shadows a function, the diagnostic when attempting to invoke the variable like a function should suggest to rename the variable or qualify the function
  • SR-9105 You can't name a nested function the same as a closure parameter.

Issue Description:

If you enable the GCC_WARN_SHADOW Xcode build setting, this is not enforced when compiling code that should raise a warning (and which does compiling the same code in Objective-C).

For example:

-(void)testGCC_WARN_SHADOW:(NSInteger)bar {
    NSInteger bar;    // get a warning here since bar local var shadows bar method param

    bar = 0;

    NSLog(@"%d", bar);  
} 

But this does not

func testGCC_WARN_SHADOW(bar: Int) {
        let bar = 0    // expect a warning here, but get none
    
        print(bar)
}

This does mean that the typical guard statement pattern also compiles without issue (which is probably desirable and correct) but could be argued to contravene this flag also.

func testGCC_WARN_SHADOW(bar : Int?) {
    guard let bar = bar else { return }
        
    print (bar)
}
@belkadan
Copy link
Contributor

belkadan commented Jun 6, 2016

There's been a fair amount of contrasting viewpoints over shadowing in Swift, which we should address directly at some point. It looks like locals shadowing parameters isn't quite covered by any of the existing JIRA bugs.

@swift-ci
Copy link
Collaborator Author

Comment by Raphael (JIRA)

I for one am confused that this is even legal. Why is a parameter not a local variable, scope-wise speaking? Re-declaring it shouldn't be possible, intuitively.

@CodaFi
Copy link
Member

CodaFi commented Jan 15, 2017

@belkadan Especially with the recent bugs due to condition resolution, I'm wondering if it would be wise to introduce this as a warning - and go to Swift-evolution about a hard error.

@belkadan
Copy link
Contributor

I don't think we get to do that. Warnings don't break source compatibility, but they are still language changes. We'd have to agree that that's the right thing to do, and it's not obvious here. (Even if I agree.)

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself feature A feature request or implementation
Projects
None yet
Development

No branches or pull requests

3 participants