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

Type signature disambiguations do not take into account same-type generic constraints when substituting Self #385

Open
tayloraswift opened this issue Jan 2, 2025 · 0 comments
Labels
bug Something isn't working

Comments

@tayloraswift
Copy link
Owner

tayloraswift commented Jan 2, 2025

this is a hole that is originally caused by the Swift compiler bug swiftlang/swift#78343 , but is not sufficiently patched by Unidoc’s downstream heuristics.

specifically, given two extensions like these

struct S<T> {}

extension S<Int> 
{
    static var x:Self { get }
}
extension S<String> 
{
    static var x:Self { get }
}

the Swift compiler will fail to resolve the Self tokens, and Unidoc’s heuristic steps in, replacing Self with S<T>. however, this substitution has no disambiguative value, as it is identical between both extensions.

the client workaround is to avoid Self and spell these extensions using the actual resolved types:

extension S<Int> 
{
-   static var x:Self { get }
+   static var x:S<Int> { get }
}
extension S<String> 
{
-   static var x:Self { get }
+   static var x:S<String> { get }
}

this would allow documentation to disambiguate between the two overloads with

-  ``S.x -> S<Int>``
-  ``S.x -> S<String>``

in theory, Unidoc could inspect the generic constraints and substitute the type arguments itself. but at this point, we are layering heuristics upon heuristics in order to compensate for what is really a plain old Swift compiler bug.

@tayloraswift tayloraswift added the bug Something isn't working label Jan 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant