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-13727] Inheritance requirement failure #56124

Open
dabrahams opened this issue Oct 13, 2020 · 3 comments
Open

[SR-13727] Inheritance requirement failure #56124

dabrahams opened this issue Oct 13, 2020 · 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

@dabrahams
Copy link
Collaborator

Previous ID SR-13727
Radar rdar://problem/70298061
Original Reporter @dabrahams
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, TypeChecker
Assignee None
Priority Medium

md5: 33d81dbfc0a5aebe387fe24a7b0d20a2

Issue Description:

Compile this:

protocol Projection {
  associatedtype Root
  associatedtype Path: PartialKeyPath<Root>
  static var path: Path { get }
}

struct ProjectKey<Key, Value>: Projection {
  typealias Root = (Key, Value)
  typealias Path = KeyPath<(Key, Value), Key>
  static var path: KeyPath<(Key, Value), Key> { \.0 }
}

This should compile and infer Root == (Key,Value) (It should also compile without the two {{typealias}}es in ProjectKey, but does not). Instead we get:

y.swift:7:8: error: type 'ProjectKey<Key, Value>' does not conform to protocol 'Projection'
struct ProjectKey<Key, Value>: Projection {
       ^
y.swift:9:13: note: possibly intended match 'ProjectKey<Key, Value>.Path' does not inherit from 'PartialKeyPath<τ_0_0.Root>'
  typealias Path = KeyPath<(Key, Value), Key>
            ^
y.swift:3:18: note: protocol requires nested type 'Path'; do you want to add it?
  associatedtype Path: PartialKeyPath<Root>
                 ^
@typesanitizer
Copy link

@swift-ci create

@slavapestov
Copy link
Member

The example you posted now type checks on master, as long as the typealiases are present. Fixing associated type inference to infer these properly seems like a separate issue. I think we have trouble looking through the superclass constraint.

@slavapestov
Copy link
Member

I think the feature you're asking for is pretty tricky. For example, consider this:

class G<T, U> {}
class Sub : G<Int, String> {}

protocol P {
  associatedtype A : G<X, Y>
  associatedtype X
  associatedtype Y

  func foo() -> A
}

struct S : P {
  func foo() -> Sub {}
}

We'd have to infer that A := Sub, and additionally X := Int, Y := String. That's a pretty complicated inference rule. I feel like it might only introduce more problems with circular decl checking and the like.

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

No branches or pull requests

3 participants