Why does the following code produce an error?
protocol ProtocolA {
var someProperty: ProtocolB { get }
}
protocol ProtocolB {}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA { // Type 'SomeClass' does not conform to protocol 'ProtocolA'
var someProperty: ConformsToB
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
}
The answer in this similar question makes sense. However, in my example, the property is get-only. Why shouldn't this work? Is it a shortcoming of Swift, or is there some reason this makes sense?
There's no real reason why this shouldn't be possible, a read-only property requirement can be covariant, as returning a ConformsToB instance from a property typed as ProtocolB is perfectly legal.
Swift just currently doesn't support it. In order to do so, the compiler would have to generate a thunk between the protocol witness table and conforming implementation in order to perform the necessary type-conversion(s). For example, a ConformsToB instance would need to be boxed in an existential container in order to be typed as ProtocolB (and there's no way the caller can do this, as it might not know anything about the implementation being called).
But again, there's no reason why the compiler shouldn't be able to do this. There are multiple bug reports open over this, this one which is specific to read-only property requirements, and this general one, in which Slava Pestov, a member of the Swift team, says:
[...] we want protocol witnesses and method overrides in every case where a function conversion is allowed
So it definitely looks like something the Swift team are looking to implement in a future version of the language.
In the mean time however, as #BallpointBen says, one workaround is to use an associatedtype:
protocol ProtocolA {
// allow the conforming type to satisfy this with a concrete type
// that conforms to ProtocolB.
associatedtype SomeProperty : ProtocolB
var someProperty: SomeProperty { get }
}
protocol ProtocolB {}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA {
// implicitly satisfy the associatedtype with ConformsToB.
var someProperty: ConformsToB
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
}
But this is quite unsatisfactory, as it means that ProtocolA is no longer usable as a type (because it has associatedtype requirements). It also changes what the protocol says. Originally it said that someProperty could return anything that conformed to ProtocolB – now it says that an implementation of someProperty deals with just one specific concrete type that conforms to ProtocolB.
Another workaround is just to define a dummy property in order to satisfy the protocol requirement:
protocol ProtocolA {
var someProperty: ProtocolB { get }
}
protocol ProtocolB {}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA {
// dummy property to satisfy protocol conformance.
var someProperty: ProtocolB {
return actualSomeProperty
}
// the *actual* implementation of someProperty.
var actualSomeProperty: ConformsToB
init(someProperty: ConformsToB) {
self.actualSomeProperty = someProperty
}
}
Here we're essentially writing the thunk for the compiler – but it's also not particularly nice as it adds a needless property to the API.
In addition to Harmish's great response, if you want to keep using the same property name on both SomeClass and ProtocolA, you can do
protocol ProtocolB {}
protocol ProtocolA {
var _someProperty_protocolA: ProtocolB { get }
}
extension ProtocolA {
var someProperty: ProtocolB {
return _someProperty_protocolA
}
}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA {
// the *actual* implementation of someProperty.
var _someProperty: ConformsToB
var someProperty: ConformsToB {
// You can't expose someProperty directly as
// (SomeClass() as ProtocolA).someProperty would
// point to the getter in ProtocolA and loop
return _someProperty
}
// dummy property to satisfy protocol conformance.
var _someProperty_protocolA: ProtocolB {
return someProperty
}
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
}
let foo = SomeClass(someProperty: ConformsToB())
// foo.someProperty is a ConformsToB
// (foo as ProtocolA).someProperty is a ProtocolB
This can be useful when you are conforming to another protocol ProtocolA2 that would originally also have constraint on someProperty as well, or when you want to hide your hack around swift limitations.
I'm now curious to know why Swift is not doing this for me directly.
Beginning in Swift 5.1, you can use opaque return types to reference a protocol that references another protocol, so long as you also use associatedtypes to do so.
Not only does it work for readonly "get" properties, but also readwrite properties. For example,
protocol ProtocolA {
associatedtype T: ProtocolB
var someProperty: T { get }
var x: Int { get set }
}
protocol ProtocolB {
var x: Int { get set }
}
struct ConformsToB: ProtocolB {
var x: Int
}
class SomeClass: ProtocolA {
var someProperty: ConformsToB
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
var x: Int {
get {
someProperty.x
}
set {
someProperty.x = newValue
}
}
}
var protocolA: some ProtocolA = SomeClass(someProperty: ConformsToB(x: 1))
print(protocolA.x) // 1
protocolA.x = 2
print(protocolA.x) // 2
Related
Why does the following code produce an error?
protocol ProtocolA {
var someProperty: ProtocolB { get }
}
protocol ProtocolB {}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA { // Type 'SomeClass' does not conform to protocol 'ProtocolA'
var someProperty: ConformsToB
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
}
The answer in this similar question makes sense. However, in my example, the property is get-only. Why shouldn't this work? Is it a shortcoming of Swift, or is there some reason this makes sense?
There's no real reason why this shouldn't be possible, a read-only property requirement can be covariant, as returning a ConformsToB instance from a property typed as ProtocolB is perfectly legal.
Swift just currently doesn't support it. In order to do so, the compiler would have to generate a thunk between the protocol witness table and conforming implementation in order to perform the necessary type-conversion(s). For example, a ConformsToB instance would need to be boxed in an existential container in order to be typed as ProtocolB (and there's no way the caller can do this, as it might not know anything about the implementation being called).
But again, there's no reason why the compiler shouldn't be able to do this. There are multiple bug reports open over this, this one which is specific to read-only property requirements, and this general one, in which Slava Pestov, a member of the Swift team, says:
[...] we want protocol witnesses and method overrides in every case where a function conversion is allowed
So it definitely looks like something the Swift team are looking to implement in a future version of the language.
In the mean time however, as #BallpointBen says, one workaround is to use an associatedtype:
protocol ProtocolA {
// allow the conforming type to satisfy this with a concrete type
// that conforms to ProtocolB.
associatedtype SomeProperty : ProtocolB
var someProperty: SomeProperty { get }
}
protocol ProtocolB {}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA {
// implicitly satisfy the associatedtype with ConformsToB.
var someProperty: ConformsToB
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
}
But this is quite unsatisfactory, as it means that ProtocolA is no longer usable as a type (because it has associatedtype requirements). It also changes what the protocol says. Originally it said that someProperty could return anything that conformed to ProtocolB – now it says that an implementation of someProperty deals with just one specific concrete type that conforms to ProtocolB.
Another workaround is just to define a dummy property in order to satisfy the protocol requirement:
protocol ProtocolA {
var someProperty: ProtocolB { get }
}
protocol ProtocolB {}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA {
// dummy property to satisfy protocol conformance.
var someProperty: ProtocolB {
return actualSomeProperty
}
// the *actual* implementation of someProperty.
var actualSomeProperty: ConformsToB
init(someProperty: ConformsToB) {
self.actualSomeProperty = someProperty
}
}
Here we're essentially writing the thunk for the compiler – but it's also not particularly nice as it adds a needless property to the API.
In addition to Harmish's great response, if you want to keep using the same property name on both SomeClass and ProtocolA, you can do
protocol ProtocolB {}
protocol ProtocolA {
var _someProperty_protocolA: ProtocolB { get }
}
extension ProtocolA {
var someProperty: ProtocolB {
return _someProperty_protocolA
}
}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA {
// the *actual* implementation of someProperty.
var _someProperty: ConformsToB
var someProperty: ConformsToB {
// You can't expose someProperty directly as
// (SomeClass() as ProtocolA).someProperty would
// point to the getter in ProtocolA and loop
return _someProperty
}
// dummy property to satisfy protocol conformance.
var _someProperty_protocolA: ProtocolB {
return someProperty
}
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
}
let foo = SomeClass(someProperty: ConformsToB())
// foo.someProperty is a ConformsToB
// (foo as ProtocolA).someProperty is a ProtocolB
This can be useful when you are conforming to another protocol ProtocolA2 that would originally also have constraint on someProperty as well, or when you want to hide your hack around swift limitations.
I'm now curious to know why Swift is not doing this for me directly.
Beginning in Swift 5.1, you can use opaque return types to reference a protocol that references another protocol, so long as you also use associatedtypes to do so.
Not only does it work for readonly "get" properties, but also readwrite properties. For example,
protocol ProtocolA {
associatedtype T: ProtocolB
var someProperty: T { get }
var x: Int { get set }
}
protocol ProtocolB {
var x: Int { get set }
}
struct ConformsToB: ProtocolB {
var x: Int
}
class SomeClass: ProtocolA {
var someProperty: ConformsToB
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
var x: Int {
get {
someProperty.x
}
set {
someProperty.x = newValue
}
}
}
var protocolA: some ProtocolA = SomeClass(someProperty: ConformsToB(x: 1))
print(protocolA.x) // 1
protocolA.x = 2
print(protocolA.x) // 2
Why does the following code produce an error?
protocol ProtocolA {
var someProperty: ProtocolB { get }
}
protocol ProtocolB {}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA { // Type 'SomeClass' does not conform to protocol 'ProtocolA'
var someProperty: ConformsToB
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
}
The answer in this similar question makes sense. However, in my example, the property is get-only. Why shouldn't this work? Is it a shortcoming of Swift, or is there some reason this makes sense?
There's no real reason why this shouldn't be possible, a read-only property requirement can be covariant, as returning a ConformsToB instance from a property typed as ProtocolB is perfectly legal.
Swift just currently doesn't support it. In order to do so, the compiler would have to generate a thunk between the protocol witness table and conforming implementation in order to perform the necessary type-conversion(s). For example, a ConformsToB instance would need to be boxed in an existential container in order to be typed as ProtocolB (and there's no way the caller can do this, as it might not know anything about the implementation being called).
But again, there's no reason why the compiler shouldn't be able to do this. There are multiple bug reports open over this, this one which is specific to read-only property requirements, and this general one, in which Slava Pestov, a member of the Swift team, says:
[...] we want protocol witnesses and method overrides in every case where a function conversion is allowed
So it definitely looks like something the Swift team are looking to implement in a future version of the language.
In the mean time however, as #BallpointBen says, one workaround is to use an associatedtype:
protocol ProtocolA {
// allow the conforming type to satisfy this with a concrete type
// that conforms to ProtocolB.
associatedtype SomeProperty : ProtocolB
var someProperty: SomeProperty { get }
}
protocol ProtocolB {}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA {
// implicitly satisfy the associatedtype with ConformsToB.
var someProperty: ConformsToB
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
}
But this is quite unsatisfactory, as it means that ProtocolA is no longer usable as a type (because it has associatedtype requirements). It also changes what the protocol says. Originally it said that someProperty could return anything that conformed to ProtocolB – now it says that an implementation of someProperty deals with just one specific concrete type that conforms to ProtocolB.
Another workaround is just to define a dummy property in order to satisfy the protocol requirement:
protocol ProtocolA {
var someProperty: ProtocolB { get }
}
protocol ProtocolB {}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA {
// dummy property to satisfy protocol conformance.
var someProperty: ProtocolB {
return actualSomeProperty
}
// the *actual* implementation of someProperty.
var actualSomeProperty: ConformsToB
init(someProperty: ConformsToB) {
self.actualSomeProperty = someProperty
}
}
Here we're essentially writing the thunk for the compiler – but it's also not particularly nice as it adds a needless property to the API.
In addition to Harmish's great response, if you want to keep using the same property name on both SomeClass and ProtocolA, you can do
protocol ProtocolB {}
protocol ProtocolA {
var _someProperty_protocolA: ProtocolB { get }
}
extension ProtocolA {
var someProperty: ProtocolB {
return _someProperty_protocolA
}
}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA {
// the *actual* implementation of someProperty.
var _someProperty: ConformsToB
var someProperty: ConformsToB {
// You can't expose someProperty directly as
// (SomeClass() as ProtocolA).someProperty would
// point to the getter in ProtocolA and loop
return _someProperty
}
// dummy property to satisfy protocol conformance.
var _someProperty_protocolA: ProtocolB {
return someProperty
}
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
}
let foo = SomeClass(someProperty: ConformsToB())
// foo.someProperty is a ConformsToB
// (foo as ProtocolA).someProperty is a ProtocolB
This can be useful when you are conforming to another protocol ProtocolA2 that would originally also have constraint on someProperty as well, or when you want to hide your hack around swift limitations.
I'm now curious to know why Swift is not doing this for me directly.
Beginning in Swift 5.1, you can use opaque return types to reference a protocol that references another protocol, so long as you also use associatedtypes to do so.
Not only does it work for readonly "get" properties, but also readwrite properties. For example,
protocol ProtocolA {
associatedtype T: ProtocolB
var someProperty: T { get }
var x: Int { get set }
}
protocol ProtocolB {
var x: Int { get set }
}
struct ConformsToB: ProtocolB {
var x: Int
}
class SomeClass: ProtocolA {
var someProperty: ConformsToB
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
var x: Int {
get {
someProperty.x
}
set {
someProperty.x = newValue
}
}
}
var protocolA: some ProtocolA = SomeClass(someProperty: ConformsToB(x: 1))
print(protocolA.x) // 1
protocolA.x = 2
print(protocolA.x) // 2
Why does the following code produce an error?
protocol ProtocolA {
var someProperty: ProtocolB { get }
}
protocol ProtocolB {}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA { // Type 'SomeClass' does not conform to protocol 'ProtocolA'
var someProperty: ConformsToB
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
}
The answer in this similar question makes sense. However, in my example, the property is get-only. Why shouldn't this work? Is it a shortcoming of Swift, or is there some reason this makes sense?
There's no real reason why this shouldn't be possible, a read-only property requirement can be covariant, as returning a ConformsToB instance from a property typed as ProtocolB is perfectly legal.
Swift just currently doesn't support it. In order to do so, the compiler would have to generate a thunk between the protocol witness table and conforming implementation in order to perform the necessary type-conversion(s). For example, a ConformsToB instance would need to be boxed in an existential container in order to be typed as ProtocolB (and there's no way the caller can do this, as it might not know anything about the implementation being called).
But again, there's no reason why the compiler shouldn't be able to do this. There are multiple bug reports open over this, this one which is specific to read-only property requirements, and this general one, in which Slava Pestov, a member of the Swift team, says:
[...] we want protocol witnesses and method overrides in every case where a function conversion is allowed
So it definitely looks like something the Swift team are looking to implement in a future version of the language.
In the mean time however, as #BallpointBen says, one workaround is to use an associatedtype:
protocol ProtocolA {
// allow the conforming type to satisfy this with a concrete type
// that conforms to ProtocolB.
associatedtype SomeProperty : ProtocolB
var someProperty: SomeProperty { get }
}
protocol ProtocolB {}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA {
// implicitly satisfy the associatedtype with ConformsToB.
var someProperty: ConformsToB
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
}
But this is quite unsatisfactory, as it means that ProtocolA is no longer usable as a type (because it has associatedtype requirements). It also changes what the protocol says. Originally it said that someProperty could return anything that conformed to ProtocolB – now it says that an implementation of someProperty deals with just one specific concrete type that conforms to ProtocolB.
Another workaround is just to define a dummy property in order to satisfy the protocol requirement:
protocol ProtocolA {
var someProperty: ProtocolB { get }
}
protocol ProtocolB {}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA {
// dummy property to satisfy protocol conformance.
var someProperty: ProtocolB {
return actualSomeProperty
}
// the *actual* implementation of someProperty.
var actualSomeProperty: ConformsToB
init(someProperty: ConformsToB) {
self.actualSomeProperty = someProperty
}
}
Here we're essentially writing the thunk for the compiler – but it's also not particularly nice as it adds a needless property to the API.
In addition to Harmish's great response, if you want to keep using the same property name on both SomeClass and ProtocolA, you can do
protocol ProtocolB {}
protocol ProtocolA {
var _someProperty_protocolA: ProtocolB { get }
}
extension ProtocolA {
var someProperty: ProtocolB {
return _someProperty_protocolA
}
}
class ConformsToB: ProtocolB {}
class SomeClass: ProtocolA {
// the *actual* implementation of someProperty.
var _someProperty: ConformsToB
var someProperty: ConformsToB {
// You can't expose someProperty directly as
// (SomeClass() as ProtocolA).someProperty would
// point to the getter in ProtocolA and loop
return _someProperty
}
// dummy property to satisfy protocol conformance.
var _someProperty_protocolA: ProtocolB {
return someProperty
}
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
}
let foo = SomeClass(someProperty: ConformsToB())
// foo.someProperty is a ConformsToB
// (foo as ProtocolA).someProperty is a ProtocolB
This can be useful when you are conforming to another protocol ProtocolA2 that would originally also have constraint on someProperty as well, or when you want to hide your hack around swift limitations.
I'm now curious to know why Swift is not doing this for me directly.
Beginning in Swift 5.1, you can use opaque return types to reference a protocol that references another protocol, so long as you also use associatedtypes to do so.
Not only does it work for readonly "get" properties, but also readwrite properties. For example,
protocol ProtocolA {
associatedtype T: ProtocolB
var someProperty: T { get }
var x: Int { get set }
}
protocol ProtocolB {
var x: Int { get set }
}
struct ConformsToB: ProtocolB {
var x: Int
}
class SomeClass: ProtocolA {
var someProperty: ConformsToB
init(someProperty: ConformsToB) {
self.someProperty = someProperty
}
var x: Int {
get {
someProperty.x
}
set {
someProperty.x = newValue
}
}
}
var protocolA: some ProtocolA = SomeClass(someProperty: ConformsToB(x: 1))
print(protocolA.x) // 1
protocolA.x = 2
print(protocolA.x) // 2
The following contrived Swift 2 example from real-world code won't compile:
protocol SomeModelType { }
protocol SomeProtocol {
var someVar: SomeModelType? { get }
}
class ConcreteClass<T: SomeModelType>: SomeProtocol {
var someVar: T?
}
This doesn't make sense to me fully. I would assume in ConcreteClass that because I have T being constrained to SomeModelType and have T as the backing type for the someVar property, the compiler would be able to figure out that the SomeProtocol was being conformed to by ConcreteClass.
How should an example like this be structured? Is it possible to the Swift compiler to determine protocol conformance through generic type constraints?
protocol SomeModelType { }
protocol SomeProtocol {
associatedtype T: Any
var someVar: T? { get }
}
class ConcreteClass<T> :SomeProtocol where T: SomeModelType {
var someVar: T?
}
I have a protocol (ProtocolA) containing a single property conforming to a second protocol (ProtocolB).
public protocol ProtocolA {
var prop: ProtocolB? { get }
}
public protocol ProtocolB {
}
I'm trying to declare two classes that will implement those:
private class ClassA : ProtocolA {
var prop: ClassB?
}
private class ClassB : ProtocolB {
}
But I get an error:
Type 'ClassA' does not conform to protocol 'ProtocolA'
Protocol requires property 'prop' with type 'ProtocolB?'
Candidate has non-matching type 'ClassB?'
Which is annoying as ClassB conforms to ProtocolB.
in the good-old i'd probably just declare the property as:
#property (nonatomic) ClassB <ProtocolB> *prop;
but the only way it seems I can get around this in swift is by adding an ivar like:
private class ClassA : ProtocolA {
var _prop: ClassB?
var prop: ProtocolB? { return _prop }
}
Is there no way around this?
You need to declare a typealias of the type that conforms to the other protocol. The way you did it is that prop has to be exactly of type ProtocolB, but you don't actually want that, you want a type that conforms to it instead.
protocol ProtocolA {
typealias Prop : ProtocolB
var prop: Prop? { get }
}
protocol ProtocolB {}
class ClassA : ProtocolA {
var prop: ClassB?
}
class ClassB : ProtocolB {}