|
|
| Previous ID |
SR-1581 |
| Radar |
None |
| Original Reporter |
vishal.panwar (JIRA User) |
| Type |
Bug |
| Status |
Resolved |
| Resolution |
Duplicate |
Additional Detail from JIRA
|
|
| Votes |
10 |
| Component/s |
Compiler |
| Labels |
Bug |
| Assignee |
None |
| Priority |
Medium |
md5: d2a9b745ccd1923da6ccec087b0df3f9
duplicates:
- 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.
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
associatedtypewith 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.