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-9792] Provide some way to call a protocol's base's overload of a method. #52217

Open
swift-ci opened this issue Jan 29, 2019 · 0 comments
Open
Labels
compiler The Swift compiler in itself improvement

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-9792
Radar None
Original Reporter CTMacUser (JIRA User)
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement
Assignee None
Priority Medium

md5: deebcaed7e6c447d14091d7689ac1588

relates to:

  • SR-117 Calling default implementation of protocols

Issue Description:

Sometimes, a protocol provides an overload of a super-protocol's method. Since it's an extension method, which one you get depends on what kind of reference you have to the receiver.

For example, the split methods used to be requirements on Sequence. Now they have moved to be extensions. These methods also exist on Collection. If you have a collection, you always get Collection.split when you call split. The only way to call the Sequence version is to wrap the object within AnySequence. You can also add an extension method to Sequence with a custom name to call Sequence.split.

But the above solution is not scaleable. You have to keep coming up with unique names and hope someone doesn't add an overload to the refined protocol. I think C++ has ways for an object to call the base type version of an overloaded method, and we should similarly add a general way to do this in Swift.

@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
compiler The Swift compiler in itself improvement
Projects
None yet
Development

No branches or pull requests

1 participant