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-10088] Subscript overloads are incorrectly allowed to differ by escaping-ness #52490

Closed
hamishknight opened this issue Mar 12, 2019 · 7 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself good first issue Good for newcomers type checker Area → compiler: Semantic analysis

Comments

@hamishknight
Copy link
Collaborator

Previous ID SR-10088
Radar None
Original Reporter @hamishknight
Type Bug
Status Resolved
Resolution Done
Environment

Swift version 5.0-dev (LLVM 94d957ca75, Swift f07a84a)
Target: x86_64-apple-darwin18.2.0

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, StarterBug, TypeChecker
Assignee jumhyn (JIRA)
Priority Medium

md5: d6e10743f8e36163cbd39a4e83fc2569

Issue Description:

For functions, we don't allow overloads to differ by escaping-ness:

struct S {
  func foo(_ fn: () -> Void) {}
  func foo(_ fn: @escaping () -> Void) {} // error: Invalid redeclaration of 'foo'
}

However we do allow this for subscripts:

struct S {
  subscript(_ fn: () -> Void) -> Int { return 0 }
  subscript(_ fn: @escaping () -> Void) -> Int { return 0 } // Okay
}

We should reject such subscript overloads like we do with functions.

@hamishknight
Copy link
Collaborator Author

Marking this as a StarterBug – the issue has to do with the overload types we assign to the declarations, from the function ValueDecl::getOverloadSignatureType() in Decl.cpp. For functions we use mapSignatureFunctionType in order to strip away things like @escaping for the purposes of redeclaration checking. We should ideally also be using this for subscripts.

Note that this is a source breaking change so would need to be guarded by a isSwiftVersionAtLeast check.

@slavapestov
Copy link
Member

It's not that source breaking. It's unlikely anyone relies on this.

@swift-ci
Copy link
Collaborator

Comment by Frederick Kellison-Linn (JIRA)

Does that mean you don’t think it needs to be version-guarded?

If no one has started work on this yet I’d be happy to take it on.

@slavapestov
Copy link
Member

I would always err on the side of simplicity. Run source compat tests first of course. We can always version-guard it later if we ship a public release with the change and people complain.

I think its rare to have subscripts take functions, period; overloading on escaping-ness is even more rare.

@hamishknight
Copy link
Collaborator Author

@slavapestov Fair enough – my main concerns were that subscripts with function parameters can come up with autoclosures, and that changing the overload signature type also affects cross-module shadowing. I do agree that it's very unlikely anyone is relying on overloading on escaping-ness though.

@swift-ci
Copy link
Collaborator

Comment by Frederick Kellison-Linn (JIRA)

Hey @xedin—just wanted to give you a heads up that I put a PR up for this issue here: #23457

Don't want you to waste time duplicating work! Sorry about that, should have assigned this bug to myself.

@xedin
Copy link
Member

xedin commented Mar 29, 2019

Thanks for letting me know!

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
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 good first issue Good for newcomers type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

4 participants