I'm having issues trying to constrain generic type requirements to just reference types. Here's some example code:
class WeakHolder<Element: AnyObject> {
weak var element: Element?
init(element: Element) {
self.element = element
}
}
protocol Animal: class { }
class Dog: Animal { }
let dog: Animal = Dog()
let holder = WeakHolder<Animal>(element: dog) // Error: Using "Animal" as a concrete type conforming to protocol 'AnyObject' is not supported.
If I change the generic requirement to <Element: class>, I get the error class constraint can only appear on protocol declarations.
Is this a limitation of generics? Marking a protocol as class is enough to have a weak reference to that protocol, is there no equivalent in generics?
The simple answer is that you cannot have a generic type that is a protocol.
Writing out the syntax makes it clear how this works:
class/struct GenericType<TypeName: TypeConstraints> {}
let thing = GenericType<Type>() where Type is a class or struct that adheres to any constraints
A Protocol Requiring adopting Types to be a class means any adopters are classes, but the Protocol itself is still not a Type.
It's possible generics could at some point support protocols, but it would require changing the general approach to either protocols or generics. Though your specific example may be possible with a smaller amount of work behind the scenes, so it's possible this may be implemented at some point.
You can take a look at The Generics Manifesto if you want to see the direction they're going. Skimming it I didn't find anything directly related to your use case, but it's fairly specific so it may not be included in the parameters of the document.
Another solution that worked in my particular case is the following:
class WeakHolder<Element: AnyObject> {
weak var element: Element?
init(element: Element) {
self.element = element
}
}
protocol Animal: class { }
class Dog: Animal { }
let dog: Animal = Dog()
let holder = WeakHolder<AnyObject>(element: dog as AnyObject)
When accessing element, I simply need to perform a downcast back to my protocol. Of course, I'll lose compile time safety when using this class with value types, but that's a non-issue in my situation.
Related
This code fails to compile with Swift 5.1
import Foundation
protocol SomeClassProtocol: AnyObject {}
class SomeClass: SomeClassProtocol {}
class GenericClass<T:AnyObject> {
weak var t: T?
init(t: T) {
self.t = t
}
}
let test = GenericClass<SomeClassProtocol>(t: SomeClass())
The error is
'GenericClass' requires that 'SomeClassProtocol' be a class type
Does the compiler really need a class type here instead of a class-only protocol?
Yes. Though the syntax is the same (a colon), protocol inheritance is not the same thing as protocol conformance. Protocols do not conform to protocols; only types can conform to protocols. (AnyObject is not special in this regard; your question is good but the title isn't getting at the issue.)
In your example:
Your T needs to conform to AnyObject. SomeClassProtocol does not conform to AnyObject. But any types that conform to SomeClassProtocol will conform to AnyObject.
So you need to pick which of these you really want:
1.
let test = GenericClass( t: SomeClass() )
(test is a GenericClass<SomeClass>.)
2.
class Class {
weak var object: AnyObject?
init(object: AnyObject) {
self.object = object
}
}
Class( object: SomeClass() )
You do have the option of subclassing, if that would be useful.
class GenericClass<T: AnyObject>: Class {
var t: T? {
get { object as? T }
set { object = newValue }
}
}
Does the compiler really need a class type here instead of a class-only protocol?
Yes, it does. I think the problem is just understanding what this means:
class GenericClass<T:AnyObject>
That means: "To resolve GenericClass, the parameterized type T must be some type that is a class." Examples would be UIView, NSString, etc.
Okay, so:
let test = GenericClass<SomeClassProtocol>(t: SomeClass())
So, SomeClassProtocol is none of those; it isn't the name of a class. It's the name of a protocol.
A further difficulty may be understanding protocols as types. They are not really full-fledged types.
You don't need to specify T explicitly.
Change your code from this:
let test = GenericClass<SomeClassProtocol>(t: SomeClass())
To this:
let test = GenericClass(t: SomeClass())
I am attempting (for essentially no reason) to make a protocol which describes categories from category theory. I have tried to come up with something like this.
protocol Category {
associatedtype Object: Protocol
}
protocol Hom {
associatedtype C: Category
associatedtype Source: C.Object
associatedtype Target: C.Object
}
In particular, I want each Hom type to have an associated category C and an associated Source and Target type which are both objects in that category. Consequently, I have associated an Object protocol to each Category, and have tried to make the Source and Target of a Hom conform to the Object protocol for the corresponding Category. The code above fails to compile with
Type 'Self.Source' constrained to non-protocol, non-class type 'Self.C.Object'
This error is at least unclear, for C.Object is declared as a protocol. Is there any way I can work around this issue?
Edit:
As Rob has pointed out, the code as is does not make much sense. Protocol is a particular class from ObjC and is not a type which describes protocols. Further, there is no type that describes all protocols, because protocols themselves cannot conform to protocols as they are just requirements on other types. What I was looking for is a metatype which Any.Protocol, Sequence.Protocol, etc. were all instances of.
I will go into more detail as to what kind of construction I am trying to describe.
A category is a type Object and a type of homomorphisms between every pair of instances of Object. For two instances of Object, A and B, the type of homomorphisms is generally written as Hom(A,B), but I will write Hom<A,B> to be Swiftier. Categories then come equipped with composition which has the signature <A: Object, B: Object, C: Object>(_ f: Hom<A,B>, _ g: Hom<B,C>) -> Hom<A,C>.
If f is an instance of Hom<A,B>, then A is called the source or domain of f and B is called the target or codomain of f.
Types themselves are then a category where Object is the metatype of all types and Hom<A,B> = (A) -> B.
The primary reason categories are difficult in Swift is because Swift does not have dependent types. There is no way to describe a category whose object type is Int because there is no way to have a type Hom<0,0>. However, if the Object type is required to be a metatype, then suddenly Hom<A,B> is a sensical thing to describe to the type system because an instance of a metatype is a type (I think), which can be a generic parameter. This is what I attempted to describe by setting Object: Protocol.
In Swift, I would really wish to describe
protocol Category {
associatedtype Object: Metatype
associatedtype Hom<A: Object, B: Object>
func compose<A: Object, B: Object, C: Object>(_ f: Hom<A,B>, then g: Hom<B,C>) -> Hom<A,C>
}
but this is also a non-starter because associated types cannot have generic parameters.
In my use case, I have a protocol that describes finitely generated abelian groups and a protocol that describes finitely generated unital rings, and I would love to write generic code which does not care whether or not it is working with GroupHom<A,B> where A: AbelianGroup, B: Abelian Group, RingHom<A,B> where A: Ring, B: Ring, or (A) -> B as each of these come equipped with the correct kind of composition.
It might just be impossible to do this, which I would be willing to accept. Please let me know if this is different enough that it should be asked as a separate question.
associatedtype Object: Protocol
This line doesn't mean what you think it means. Protocol isn't part of Swift. It's part of the ObjC runtime. (It's a really confusing import.)
But even if it did mean that, I don't believe it would help you. It is important to realize that in Swift, protocols do not conform to protocols, and protocols with associated types are not types. They're constraints on types. This tends to creep in all over the place and surprise people.
My suspicion is that you're looking to model things along these lines (note that my category theory is very weak, so please forgive me if I use the wrong terms at points).
We want to get to a point where we can say "a category has a collection of objects and a collection of arrows between those objects." To get there, I think we'd want to start with a generic Arrow:
protocol Arrow {
associatedtype Source
associatedtype Target
var apply: (Source) -> Target { get }
}
A homomorphism is an arrow that maps back to its own type.
protocol Homomorphism: Arrow where Source == Target {
typealias Object = Source
}
And with that, we can express a Category:
protocol Category {
associatedtype Object
associatedtype Arrow: Homomorphism where Arrow.Object == Object
}
I'd like to talk about the category of integers and functions (I believe that's a proper category). So first I need functions.
struct Function<Source, Target>: Arrow {
let apply: (Source) -> Target
}
extension Function: Homomorphism where Source == Target {}
And then I can declare the category.
struct Integers: Category {
typealias Object = Int
typealias Arrow = Function<Int, Int>
}
And create a morphism.
let increment = Function(apply: { (x: Int) in x + 1 })
I think this is somewhat the direction you're looking for.
dg
In swift you cannot use a protocol associatedtype as an associatedType cause it is not defined what type is.
Associated Type can only be used as a constraint for types, like this:
protocol Category {
associatedtype Object1:Equatable
}
class Homs:Category{
typealias Object1 = Int
func sum(element:Object1){
print(element+element)
}
}
Or like this
protocol Category {
associatedtype Object1: Equatable
}
protocol Homs {
associatedtype Cat:Category
associatedtype Source: Category where Source.Object1 == Cat.Object1
associatedtype Target: Category where Target.Object1 == Cat.Object1
}
The reason of why your code not compile, is cause, your associatedtype Target is constrained to implements a associatedType (that is not defined) of a protocol. Someone need to define it before to use as a constraint.
An approach to resolve your problem clould be, generate a generic class. Let's to see it:
protocol Category {
associatedtype Object1: Equatable
}
class Homs<Cat:Category,Source,Target> where Cat.Object1 == Source && Cat.Object1 == Target.Object1{
}
Another approach could be create a generic Category class, and a protocol with type for Category class, category Class, Source and Target conforming to Type:
class Category<T>{
}
protocol Homs {
associatedtype ObjectType
associatedtype Cat:Category<ObjectType>
associatedtype Source where Source == ObjectType
associatedtype Target where Target == ObjectType
}
O something like the second example:
protocol Category {
associatedtype Object1: Equatable
}
protocol Homs {
associatedtype Cat:Category
associatedtype Source: Category where Source.Object1 == Cat.Object1
associatedtype Target: Category where Target.Object1 == Cat.Object1
}
Remember, You cannot use protocols with associated types as a type constraint for associated type or as a type for a variable or constant, first someone need to define the associated types.
I hope I helped you.
I have a generic class of the form:
class BaseClass<T> {
var prop: T
...
}
I then have multiple subclasses of the form:
class SubClassOne: BaseClass<SomeSubClass> {
...
}
class SubClassTwo: BaseClass<SomeOtherSubClass> {
...
}
Where the type parameters SomeSubClass and SomeOtherSubClass both inherit from a common base class SomeBaseClass.
I now want to define a variable to store instances of both SubClassOne and SubClassTwo. I have tried many possibilities:
var obj: BaseClass
var obj: BaseClass<SomeBaseClass>
var obj: BaseClass<Any>
But the first attempt results in the error Reference to generic type 'BaseClass' requires arguments in <...>, and the other two result in the error Cannot assign value of type 'SubClassOne' to type ... when trying to assign a value. I even tried to trick the Swift compiler into inferring the type for me by initializing an array:
var testArray = [SubClassOne(), SubClassTwo()]
But even this failed, resulting in the error Heterogeneous collection literal could only be inferred to [Any]; add explicit type annotation if this is intentional. Indeed, the only type annotation that successfully allows storage of both SubClasses is Any or AnyObject. Is it possible to store these instances with a more specific type? If not, why?
The reason it's important to do so is that I ultimately want to get the property prop from the stored variable obj. I am unable to do so if obj is stored as Any. I am also unable to simply cast it to SubClassOne or SubClassTwo because the method itself where I am trying to access the properties is a generic method, and which of SubClassOne or SubClassTwo to cast to depends on the generic type parameter of the method:
func castObj<T>(asType: T.Type) {
(self.obj as? T).prop
}
Which would be called as: castObj(asType: SubClassOne.self) or castObj(asType: SubClassTwo.self). However, we run into the same problem: the only generic type parameter constraint I can define that accepts both SubClassOne and SubClassTwo is Any, and then the Swift compiler complains: Value of type 'T' has no member 'prop'.
As a workaround I tried to define a protocol that encapsulates the desired property:
protocol HasProp {
var prop: SomeBaseClass { get }
}
Then I added this to the declaration of SubClassOne and SubClassTwo. However this resulted in still another error: Type 'SubClassOne' does not conform to protocol 'HasProp'. This confuses me as well, since SubClassOne and SubClassTwo both inherit prop from BaseClass<SomeSubClass> and so actually do conform to the protocol.
In summary:
Is it possible to store instances of SubClassOne and SubClassTwo with a more specific type that gives access to properties of BaseClass? If not, why?
Why do the SubClasses not conform to the protocol as expected?
How can I change the design to attain my desired behavior?
The problem is that at the moment the function castObj has no type constraints for its generic parameter, T. By giving a type constraint of BaseClass you should be fine, since BaseClass has both properties.
func castObj<T: BaseClass>(asType: T.Type) {
(self.obj as? T).propOne
(self.obj as? T).propTwo
}
In your example, the type of propTwo was common to both subclasses and the type of propOne was specialized. Make your design reflect that.
[was]
class BaseClass<T,U> {
var propOne: T
var propTwo: U
...
}
class SubClassOne: BaseClass<SomeSubClass, SomeClass> {}
class SubClassTwo: BaseClass<SomeOtherSubClass, SomeClass> {}
[could be]
class BaseClass<U> {
var propTwo: U
...
}
class SubClassOne<T>: BaseClass<SomeClass> {
var propOne: T
...
}
class SubClassTwo<T>: BaseClass<SomeClass> {
var propOne: T
...
}
The point is to keep common things in the base class and compose your specializations.
There's a fundamental misconception that SubclassOne and SubclassTwo are in the same inheritance hierarchy. Because of the generic type, they inherit from different base classes. You cannot mix and match them.
Think about it. With inheritance you should be able to use any subclass anywhere where you have the base class, so in your test example:
var testArray = [SubClassOne(), SubClassTwo()]
What type would the right hand side of the following expressions have to be?
testArray[0].prop = something
And this one
testArray[1].prop = something;
In SubClassOne, the type of prop is SomeSubClass and in SubClassTwo the type of prop must be SomeOtherSubClass.
The only way for you to get this to work is for prop to be declared as SomeBaseClass and that removes the necessity for BaseClass to be generic.
Edit
Why doesn't the protocol work?
The problem with the protocol is that you define the property as having the type of the base class but it is read/write. A property in an implementation of the protocol cannot fulfill the contract with a property that is specialised to one of the subclasses because other bits of code need to be able to assign any instance of the base class to the property.
protocol MyProtocol
{
var prop: BaseClass
}
struct MyImplementation: MyProtocol
{
var prop: SubClass
}
class BaseClass {}
class SubClass: BaseClass {}
class DifferentSubClass: BaseClass {}
var instance: MyProtocol = MyImplementation()
instance.prop = DifferentSubClass()
// Should be legal because the protocol says so but the type of prop in instance is SubClass.
In my swift project I have a case where I use protocol inheritance as follow
protocol A : class{
}
protocol B : A{
}
What Im trying to achieve next is declaring another protocol with associated type, a type which must inherit from protocol A. If I try to declare it as :
protocol AnotherProtocol{
associatedtype Type : A
weak var type : Type?{get set}
}
it compiles without errors but when trying to adopt AnotherProtocol in the following scenario:
class SomeClass : AnotherProtocol{
typealias Type = B
weak var type : Type?
}
compilation fails with error claiming that SomeClass does not conform to AnotherProtocol. If I understood this correctly it means that B
does not adopt A while Im trying to declare and asking you on how to declare an associated type which inherits from protocol A?
I made the above assumption based on fact that the following scenario compiles just fine
class SomeDummyClass : B{
}
class SomeClass : AnotherProtocol{
typealias Type = SomeDummyClass
weak var type : Type?
}
This is pretty interesting. It appears that once you constrain the type of an associatedtype in a given protocol, you need to provide a concrete type in the implementation of that protocol (instead of another protocol type) – which is why your second example worked.
If you remove the A constraint on the associated type, your first example will work (minus the error about not being able to use weak on a non-class type, but that doesn’t seem to be related).
That all being said, I can't seem to find any documentation in order to corroborate this. If anyone can find something to back this up with (or completely dispute it), I’d love to know!
To get your current code working, you can use generics. This will actually kill two birds with one stone, as both your code will now compile and you'll benefit from the increased type safety that generics bring (by inferring the type you pass to them).
For example:
protocol A : class {}
protocol B : A {}
protocol AnotherProtocol{
associatedtype Type : A
weak var type : Type? {get set}
}
class SomeClass<T:B> : AnotherProtocol {
typealias Type = T
weak var type : Type?
}
Edit: It appears the above solution won't work in your particular case, as you want to avoid using concrete types. I'll leave it here in case it's useful for anyone else.
In your specific case, you may be able to use a type erasure in order to create a pseudo concrete type for your B protocol. Rob Napier has a great article about type erasures.
It's a bit of a weird solution in this case (as type erasures are normally used to wrap protocols with associatedtypes), and it's also definitely less preferred than the above solution, as you have to re-implement a 'proxy' method for each method in your A & B protocols – but it should work for you.
For example:
protocol A:class {
func doSomethingInA() -> String
}
protocol B : A {
func doSomethingInB(foo:Int)
func doSomethingElseInB(foo:Int)->Int
}
// a pseudo concrete type to wrap a class that conforms to B,
// by storing the methods that it implements.
class AnyB:B {
// proxy method storage
private let _doSomethingInA:(Void)->String
private let _doSomethingInB:(Int)->Void
private let _doSomethingElseInB:(Int)->Int
// initialise proxy methods
init<Base:B>(_ base:Base) {
_doSomethingInA = base.doSomethingInA
_doSomethingInB = base.doSomethingInB
_doSomethingElseInB = base.doSomethingElseInB
}
// implement the proxy methods
func doSomethingInA() -> String {return _doSomethingInA()}
func doSomethingInB(foo: Int) {_doSomethingInB(foo)}
func doSomethingElseInB(foo: Int) -> Int {return _doSomethingElseInB(foo)}
}
protocol AnotherProtocol{
associatedtype Type:A
weak var type : Type? {get set}
}
class SomeClass : AnotherProtocol {
typealias Type = AnyB
weak var type : Type?
}
class AType:B {
// implement the methods here..
}
class AnotherType:B {
// implement the methods here..
}
// your SomeClass instance
let c = SomeClass()
// set it to an AType instance
c.type = AnyB(AType())
// set it to an AnotherType instance
c.type = AnyB(AnotherType())
// call your methods like normal
c.type?.doSomethingInA()
c.type?.doSomethingInB(5)
c.type?.doSomethingElseInB(4)
You can now use the AnyB type in place of using the B protocol type, without making it any more type restrictive.
I’m trying to mix generics with protocols and I’m getting a really hard time xD
I have certain architecture implemented in an Android/Java project, and I’m trying to rewrite it to fit it in a swift/iOS project. But I’ve found this limitation.
ProtocolA
protocol ProtocolA {
}
ProtocolB
protocol ProtocolB : ProtocolA {
}
ImplementProtocolA
class ImplementProtocolA <P : ProtocolA> {
let currentProtocol : P
init(currentProtocol : P) {
self.currentProtocol = currentProtocol
}
}
ImplementProtocolB
class ImplementProtocolB : ImplementProtocolA<ProtocolB> {
}
So, when I try to set ProtocolB as the concrete type that implements ProtocolA, I get this error:
Using 'ProtocolB' as a concrete type conforming to protocol 'ProtocolA' is not supported
1 Is there any reason for this “limitation”?
2 Is there any workaround to get this implemented?
3 Will it be supported at some point?
--UPDATED--
Another variant of the same problem, I think:
View protocols
protocol View {
}
protocol GetUserView : View {
func showProgress()
func hideProgress()
func showError(message:String)
func showUser(userDemo:UserDemo)
}
Presenter protocols
protocol Presenter {
typealias V : View
}
class UserDemoPresenter : Presenter {
typealias V = GetUserView
}
Error:
UserDemoPresenter.swift Possibly intended match 'V' (aka
'GetUserView') does not conform to 'View’
What is that?? It conforms!
Even if I use View instead of GetUserView, it does not compile.
class UserDemoPresenter : Presenter {
typealias V = View
}
UserDemoPresenter.swift Possibly intended match 'V' (aka 'View') does
not conform to 'View'
xxDD I don’t get it, really.
--UPDATED--
With the solution proposed by Rob Napier the problem is not fixed, instead, it is just delayed.
When a try to define a reference to UserDemoPresenter, I need to specify the generic type, so I get the same error:
private var presenter : UserDemoPresenter<GetUserView>
Using 'GetUserView' as a concrete type conforming to protocol
'GetUserView' is not supported
The underlying reason for the limitation is that Swift doesn't have first-class metatypes. The simplest example is that this doesn't work:
func isEmpty(xs: Array) -> Bool {
return xs.count == 0
}
In theory, this code could work, and if it did there would be a lot of other types I could make (like Functor and Monad, which really can't be expressed in Swift today). But you can't. You need to help Swift nail this down to a concrete type. Often we do that with generics:
func isEmpty<T>(xs: [T]) -> Bool {
return xs.count == 0
}
Notice that T is totally redundant here. There is no reason I should have to express it; it's never used. But Swift requires it so it can turn the abstract Array into the concrete [T]. The same is true in your case.
This is a concrete type (well, it's an abstract type that will be turned into a concrete type any time it's instantiated and P is filled in):
class ImplementProtocolA<P : ProtocolA>
This is a fully abstract type that Swift doesn't have any rule to turn into a concrete type:
class ImplementProtocolB : ImplementProtocolA<ProtocolB>
You need to make it concrete. This will compile:
class ImplementProtocolB<T: ProtocolB> : ImplementProtocolA<T> {}
And also:
class UserDemoPresenter<T: GetUserView> : Presenter {
typealias V = T
}
Just because you're likely to run into the issue later: your life will go much easier if you'll make these structs or final classes. Mixing protocols, generics, and class polymorphism is full of very sharp edges. Sometimes you're lucky and it just won't compile. Sometimes it will call things you don't expect.
You may be interested in A Little Respect for AnySequence which details some related issues.
private var presenter : UserDemoPresenter<GetUserView>
This is still an abstract type. You mean:
final class Something<T: GetUserView> {
private var presenter: UserDemoPresenter<T>
}
If that creates a problem, you'll need to create a box. See Protocol doesn't conform to itself? for discussion of how you type-erase so that you can hold abstract types. But you need to work in concrete types. You can't ultimately specialize on a protocol. You must eventually specialize on something concrete in the majority of cases.