You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
swift-ci opened this issue
Jun 5, 2016
· 4 comments
Labels
bugA deviation from expected or documented behavior. Also: expected but undesirable behavior.compilerThe Swift compiler in itselffeatureA feature request or implementation
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 {
NSIntegerbar; // get a warning here since bar local var shadows bar method parambar = 0;
NSLog(@"%d", bar);
}
But this does not
functestGCC_WARN_SHADOW(bar: Int) {
letbar = 0// expect a warning here, but get noneprint(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.
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.
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.
@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.
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.)
bugA deviation from expected or documented behavior. Also: expected but undesirable behavior.compilerThe Swift compiler in itselffeatureA feature request or implementation
Additional Detail from JIRA
md5: 3393657e7a6fab4aa1fc1b329a47aa67
is duplicated by:
relates to:
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:
But this does not
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.
The text was updated successfully, but these errors were encountered: