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-11508] Generic Type inference breaks when generic object gets passed into closure #53909

Closed
swift-ci opened this issue Sep 23, 2019 · 3 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-11508
Radar rdar://problem/55665254
Original Reporter dseitz (JIRA User)
Type Bug
Status Resolved
Resolution Invalid

Attachment: Download

Environment

macOS Mojave 10.14.6

XCode 12.1

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, TypeChecker
Assignee None
Priority Medium

md5: b9acd932aa1c486b7bf0ac1038700e73

Issue Description:

If I have a generic object (lets call it Builder) with a generic method with type constraints that I pass another generic object (lets call it Transformer) into the compiler seems to be able to figure out the type that Transformer should be if it is at all possible. However if instead of using the Builder object directly I create a closure that takes Builder the same exact code shows a compiler error saying the generic types are not matching. See attached file for more details.

@belkadan
Copy link
Contributor

@swift-ci create

@CodaFi
Copy link
Member

CodaFi commented Oct 24, 2019

I think this one is correct. I think what you want here is for `TransformerObject` to look like this instead:

struct TransformerObject<Output: SomeClass>: Transformer {
    func modify(input: Int, output: Output) -> Output {
        return output
    }
}
let builder = Builder(input: Int(0), output: SomeSubclass())
    .add(transformer: TransformerObject())
// This works too
builder.add(transformer: TransformerObject())

These two work because your builder is a Builder<Int, SomeClass>, and SomeSubclass <: SomeClass. When you refine the bound to SomeSubclass, notice that you are satisfying Transformer.Input with SomeClass. As it is not the case that SomeClass <: SomeSubclass (else we would contradict the first subtyping judgement or introduce a circular class hierarchy), the type checker complains.

Along with this, your call to

Builder.add(_🙂 in the refined closure needs to explicitly state SomeSubclass, otherwise the best we can do is see the Output: SomeClass bound and pick SomeClass.

Altogether now!

struct TransformerObject<Output: SomeClass>: Transformer {
    func modify(input: Int, output: Output) -> Output {
        return output
    }
}

// This works
let builder = Builder(input: Int(0), output: SomeSubclass())
    .add(transformer: TransformerObject())

// This works too
builder.add(transformer: TransformerObject())

// This works
let brokenClosure: (Builder<Int, SomeSubclass>) -> SomeSubclass = { builder in
    builder.add(transformer: TransformerObject<SomeSubclass>()).build()
}

@xedin
Copy link
Member

xedin commented May 8, 2020

dseitz (JIRA User) I think @CodaFi is correct here, compiler behaves correct and even produces useful error message in this case:

error: instance method 'add(transformer:)' requires the types 'SomeSubclass' and 'SomeClass' be equivalent
        builder.add(transformer: TransformerObject()).build()
        ^
note: where 'Output' = 'SomeSubclass', 'T.Output' = 'SomeClass'
        func add<T: Transformer>(transformer: T) -> Builder where T.Output == Output {
             ^

@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 type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

4 participants