“SwiftData inheritance relationship”

Could you explain what the advantage of this is compared to simply use Animal as Superclass and Cat & Dog as Subclasses? This is classic inheritance. What good do generics and protocols bring here? I'm totally confused.

I still don't get why use generics here instead of the perfectly fine working inheritance...

A simple example:extension Comparable { func clampedBetween(minVal: Self, and maxVal: Self) -> Self { return self < minVal ? minVal : self > maxVal ? maxVal : self } }This will give you the ability to do x.clampedBetween(y and z) for x, y, z of any type that conforms to the protocol Comparable (Int, Double, Float, UInt8, ...), and also any new type you make which conforms to Comparable. This will work statically and you will get compile time errors if you try to clamp a value with min and max values of a different type (which is of course a good thing).This would not be possible using inheritance.

Try to restore without backup... These problems appears sometimes when inherited data from previous versions are incompatible and/or invalid. Probably, newer versions will fix it doing some data conversion.

The problem is not that you can't pass a Dog to that constructor or change the value to a Cat, but that FetchedResults<Dog> is considered a completely different type from FetchedResults<Animal>.You'll see that adding this line to your code won't work:animals = FetchedResults<Dog>(object: Dog())If animals is declared as FetchedResults<Animal>, there is no way to assign it a FetchedResults<Dog> or FetchedResults<Cat>.Variance is about the relationship between the type as a whole and the generic parameter. What covariance means is that these two may covary, so FetchedResults<Dog> would be considered a subtype of FetchedResults<Animal>. This currently happens with arrays and other collection types (so [Dog] is considered a subtype of [Animal]) but is not possible for your own types.This is pretty common in other languages and is something Swift developers have indicated will be available in the future. With lightweight generics in Objective-C it seems there

Well I still don't get what is missing here. Inheritance works perfectly fine. So where comes the need for genereics in here? 😕

I'm assuming you mean for classes that don't inherit from NSObject? There is an is type check operator (see Checking Type in the manual), but it will always return true when checking a superclass:import UIKit class SuperA { } class B: SuperA { } class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view, typically from a nib. let bInstance: SuperA = B() if bInstance is SuperA { // warning: 'is' test is always true print(true) } else { print(false) } } }I'm guessing you already knew about that though, since you say you are asking for something that returns false. Sorry I don't have an answer, but I thought maybe this would clarify your question for others that may read this thread.

The generic type Array does not conform to Equatable. This can be further confirmed by eg:extension Array: Equatable {} // Error: Type 'Array' does not conform to protocol 'Equatable'If Array had been Equatable, we would instead have seen the same error message as the one we get for eg String (which is Equatable):extension String: Equatable {} // Error: Redundant conformance of 'String' to protocol 'Equatable'But why does your check work?While something like the following seems to suggest that Array conforms to Equatable:let a = [Hello, world] let b = [Hello, world] print(a == b) // Prints true, but doesn't mean Array is Equatable ...It's not actually the case.If we examine what is actually happening by jumping to the definition of that == in the std lib (ctrl-cmd-J on it), we'll see this:/// Returns true if these arrays contain the same elements. func ==<T : Equatable>(lhs: [T], rhs: [T]) -> BoolNote that the T there is not the Array itself, it's just the Element type of the array type, the arrays a

I could make a class that inherits from UIView (or whatever base class I need) and conforms to the protocol and stub the methods. Then subclass it to my concrete subclasses where I actually implement the methods, but this is a rather messy solution, questioning the role of the protocol.Because I use a protocol exactly because implementation differs in the different subclasses, it's the interface (protocol) that stays the same.For me it is a feature omission. It is something that was there in Obj-C and had it's use cases.

I think this is just a current limitation of the type system, since there is a rather specific error if you try to do this (Extension of type 'TypeName' with constraints cannot have an inheritance clause). It's definitely a little disappointing. I filed a Radar (#21507148), and I'm sure others have done so as well.