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

Jump to bottom

[SR-13725] @dynamicMemberLookup doesn't work with key paths more than one level deep #56122

Closed
layoutSubviews opened this issue Oct 12, 2020 · 2 comments
Closed

[SR-13725] @dynamicMemberLookup doesn't work with key paths more than one level deep #56122

layoutSubviews opened this issue Oct 12, 2020 · 2 comments
Assignees
@layoutSubviews
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

@layoutSubviews
Copy link

Previous ID SR-13725
Radar None
Original Reporter @layoutSubviews
Type Bug
Status Closed
Resolution Invalid
Environment

Xcode 12.2 beta 2 (12B5025f)

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

md5: c774366020bcc8d95efe2818a50fdc20

Issue Description:

Considering this snippet:

struct Resource { }

struct Bar {
    struct Baz {
        var resource: Resource { Resource() }
    }
    var baz: Baz { Baz() }
}

@dynamicMemberLookup
struct Foo {

    subscript(dynamicMember keyPath: KeyPath<Bar, Resource>) -> Resource {
        Bar()[keyPath: keyPath]
    }

}

// This line builds
let r1: Resource = Foo()[dynamicMember: \.baz.resource]
// This line doesn't
let r2: Resource = Foo().baz.resource

I'm expecting the `let r2` line to compile successfully, as `.baz.resource` is a perfectly valid `KeyPath<Bar, Resource>`.
@theblixguy
Copy link
Collaborator

I replied on Twitter, but posting here for future reference. Foo().baz.resource would be evaluated here as Foo()[dynamicMember: .baz].resource. The problem is that the dynamicMember KeyPath has a type KeyPath<Bar, Resource> but .baz produces a value of type Baz and not Resource. So, the member access cannot be performed. The diagnostic we produce is also very poor ("type of expression is ambiguous without more context") unfortunately. I think we should fix that.

Anyhow, to fix the problem you're facing, you can make the KeyPath value type generic instead - subscript<U>(dynamicMember keyPath: KeyPath<Bar, U>) -> U or you can explicitly specify the correct type which would be Bar.Baz - subscript(dynamicMember keyPath: KeyPath<Bar, Bar.Baz>) -> Bar.Baz.

@layoutSubviews
Copy link
Author

Thank you @theblixguy for the great explanation. I'll close this ticket accordingly.

@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
Assignees

@layoutSubviews layoutSubviews

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
Milestone
No milestone
Development

No branches or pull requests
2 participants
@theblixguy @layoutSubviews