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-9626] Unexpected behavior of static constructor's type inference #52072

Closed
swift-ci opened this issue Jan 9, 2019 · 2 comments
Closed

[SR-9626] Unexpected behavior of static constructor's type inference #52072

swift-ci opened this issue Jan 9, 2019 · 2 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

swift-ci commented Jan 9, 2019

Previous ID SR-9626
Radar rdar://problem/47324309
Original Reporter domas (JIRA User)
Type Bug
Status Closed
Resolution Done
Environment

macOS Mojave Version 10.14.2 (18C54)
Xcode Version 10.1 (10B61)
Apple Swift version 4.2.1 (swiftlang-1000.11.42 clang-1000.11.45.1)

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

md5: b4bfa621d7cc84553991cf9637b2262b

Issue Description:

1. Given a base class, it's subclass, a generic struct and a generic func we can have this arrangement:

class BaseClass {}
class SubClass: BaseClass {}
struct Box<T> { init(_: T.Type) {} }

func test<T>(box: Box<T>) -> T.Type {
    return T.self
}

test(box: .init(SubClass.self)) // Results with expected `SubClass.Type`

This works as expected. Though there are 2 easy ways to break the result of `func test`.

2.1. Adding a type constraint on `func test`:

class BaseClass {}
class SubClass: BaseClass {}
struct Box<T> { init(_: T.Type) {} }

func test<T: BaseClass>(box: Box<T>) -> T.Type {
    return T.self
}

test(box: .init(SubClass.self)) // Unexpectedly results with `BaseClass.Type`

2.2. Adding a type constraint on `Box`:

class BaseClass {}
class SubClass: BaseClass {}
struct Box<T: BaseClass> { init(_: T.Type) {} }

func test<T>(box: Box<T>) -> T.Type {
    return T.self
}

test(box: .init(SubClass.self)) // Unexpectedly results with `BaseClass.Type`

What's even more unexpected is that adding another func named `test` to 2.1. and 2.2. changes the result back to `SubClass.Type`:

3.1. Adding anoter `func test` to 2.1:

class BaseClass {}
class SubClass: BaseClass {}
struct Box<T> { init(_: T.Type) {} }

func test<T: BaseClass>(box: Box<T>) -> T.Type {
    return T.self
}

func test(someParameter: Any) {}

test(box: .init(SubClass.self)) // Now results with `SubClass.Type`

3.2. Adding anoter `func test` to 2.2:

class BaseClass {}
class SubClass: BaseClass {}
struct Box<T: BaseClass> { init(_: T.Type) {} }

func test<T>(box: Box<T>) -> T.Type {
    return T.self
}

func test(someParameter: Any) {}

test(box: .init(SubClass.self)) // Now results with `SubClass.Type`
@belkadan
Copy link
Contributor

belkadan commented Jan 9, 2019

I can see why there's an ambiguity, because SubClass.self is a valid BaseClass, but it certainly does seem like the behavior should be consistent here. cc @xedin

@xedin
Copy link
Member

xedin commented Jan 17, 2019

Thank you for the report, domas (JIRA User)! I've merged PR #21931 which is going to resolve this issue, please use the next available master nightly build to verify and close this issue.

@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

3 participants