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-11183] There should be a way to disambiguate methods/properties/nested types with the same name in the same type defined in extensions in different modules #53580

Open
swift-ci opened this issue Jul 22, 2019 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-11183
Radar rdar://problem/17275821
Original Reporter broadway_lamb (JIRA User)
Type Bug
Additional Detail from JIRA
Votes 2
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: 88bc464882feb2ff1ad6082004a35c49

relates to:

  • SR-1842 Introduce syntax for explicitly invoking extension methods.

Issue Description:

Right now if two modules extend a type with a method/property with the same name, there's no way to refer to any of them in a client module:

// Module A
extension Int {
    public struct Nested {
        public init() {}
    }
    public func whatModuleIsThis() -> String { "A" }
}

// Module B
extension Int {
    public struct Nested {
        public init() {}
    }
    public func whatModuleIsThis() -> String { "B" }
}

// Module C
import A
import B

func ambiguous(_ n: Int) -> String {
    // error: Ambiguous type name 'Nested' in 'Int'
    return n.whatModuleIsThis() + String(describing: Int.Nested())
}

I couldn't find a bug for this, so I figured I should create one.

I'd like to work on supporting this in the compiler, and then pitch a syntax for disambiguation, with a working implementation.

@swift-ci
Copy link
Collaborator Author

Comment by Sergej Jaskiewicz (JIRA)

I've created a PR that prepares some ground for this feature.

#26186

@belkadan
Copy link
Contributor

Some syntax spitballing from our Radar:

[1, 2, 3].MyModule::myMethod
[1, 2, 3].(MyModule.myMethod)
[1, 2, 3].`MyModule.myMethod`
[1, 2, 3].MyModule#myMethod
[1, 2, 3].myMethod@MyModule

@swift-ci
Copy link
Collaborator Author

Comment by Sergej Jaskiewicz (JIRA)

@belkadan I had in mind the first option with :: and it looks good to me, but I'd also want to discuss this one:

[1, 2, 3].(MyModule)myMethod

This has the advantage of more precise code completion: as soon as we see an lparen following a period, we can suggest only module names like we do when completing an import declaration, but, unlike the second option in your list, the module parens are not too close to call parens, and we save one period. Compare:

[1, 2, 3].(MyModule.myMethod)()
[1, 2, 3].(MyModule)myMethod()

I actually have a prototype implementation of this solution locally but want to also implement the one with a double colon so that everybody could check out both variants and play with them.

@belkadan
Copy link
Contributor

I find it hard to read, but it's as valid an option as anything else. I'm sure we're going to get plenty of bikeshedding on the forums.

(I do remember people talking about .(foo) as shorthand for .init(foo), but that was no more real syntax than this is.)

@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
Projects
None yet
Development

No branches or pull requests

2 participants