SR-55 non-@objc protocol existentials do not conform to their own protocol type
is duplicated by:
SR-11340 Compilation error when there shouldn't be one
relates to:
SR-55 non-@objc protocol existentials do not conform to their own protocol type
SR-2020 Protocol composition doesn't conform to associated type requirement
Issue Description:
The following code sample does not compile.
protocol Bar {
}
protocol Buz: Bar {
}
protocol Foo {
associatedtype SomeType: Bar
func someOperation(someType: SomeType)
}
struct Quack: Foo {
func someOperation(someType: Buz) {
}
}
It throws error:
Inferred type 'Buz' (by matching requirement 'someOperation') is invalid: does not conform to 'Bar'
I am not sure if we are only allowed to use a concrete type for associatedtype with protocol constraint. I don't see any reason for this restriction. If we remove the protocol constraint from associatedtype, then it compiles with no error.
Update 2016/12/12: I am using below workaround to tackle above bug. This seems more logical and makes me feel like its not a bug.
struct Quack<T>: Foo where T: Buz {
func someOperation(someType: T) {
}
}
// Usage
struct SomeBuz: Buz {}
let quack: Quack<SomeBuz> = Quack<SomeBuz>()
quack.someOperation(SomeBuz())
The reason this makes more sense to me is that the compiler now has more context on the actual type.
The text was updated successfully, but these errors were encountered:
+1 for this. The thing that we want to express is safe; if there are nuances with the current syntax we should devise a way to make it possible.
protocolA {}
protocolSubA : A {}
protocolB { associatedtypeTypeOfA : A }
structMyB : B { // ERROR: `MyB` does not conform to `B`typealiasTypeOfA = SubA
}
Additional Detail from JIRA
md5: d2a9b745ccd1923da6ccec087b0df3f9
duplicates:
is duplicated by:
relates to:
Issue Description:
The following code sample does not compile.
It throws error:
I am not sure if we are only allowed to use a concrete type for
associatedtype
with protocol constraint. I don't see any reason for this restriction. If we remove the protocol constraint fromassociatedtype
, then it compiles with no error.Update 2016/12/12: I am using below workaround to tackle above bug. This seems more logical and makes me feel like its not a bug.
The reason this makes more sense to me is that the compiler now has more context on the actual type.
The text was updated successfully, but these errors were encountered: