“SwiftData inheritance relationship”

>> This code behaves as it does because protocol extensions are compile-time constructs.The problem with this is that it doesn't seem to be viable, as a compiler behavior:1. In the case of a class type conforming to the protocol(s) involved, the existing semantics of inheritance say that it doesn't matter (to instances of a subclass) whether a method is implemented in the subclass or a base class (when it's only implemented in one place, I mean, I'm not talking about overrides). If that weren't true, then it wouldn't be safe to factor behavior out of subclasses into base classes.2. In your 'extension Foo' example, the issue isn't whether the doFoo method is a compile-time construct, but the fact that 'self' already means something in terms of method lookup — it means to start with the class of the instance that's executing the code**. Unfortunately, in the current Swift, it means something else, apparently to start with a class chosen at compile time. Whatever that is, it isn't what 'self' mean

I'm not sure that I understand the point you're making here, so please correct me if I'm misinterpreting. (And note also, I'm going to just ignore potential @objc complications.)I think you're saying that given the following code context,protocol P { func p() } extension P { func p() { print(Called default p implementation) } } class C: P {} func someFunction(obj: C) { obj.p() }the dispatch of obj.p() on line 12 must take account of the fact that obj may in fact be a subclass of C with its own p() implementation, and that that subclass's implementation of p() should be called in preference to the default p(). Otherwise, OO method inheritance might be considered broken.However, that is not in fact the behavior of the current implementation:// This is a continuation of the previous code... class D: C { func p() { print(Called D's p implementation) } } someFunction(D()) // Calls the default p implementationI agree that this is weird. I'm just pointing out that this is how it works.Mechanically, I think

>> However, that is not in fact the behavior of the current implementation:>> […]>> I agree that this is weird. I'm just pointing out that this is how it works.I'm saying it's not just weird, it's wrong. The really weird thing is that it's wrong in 3 completely separate ways:1. P's p and D's p are actually unrelated methods of the same name. Note that there's no error message stating that D's p needs an override keyword, or that the two p's conflict (which they do).2. Class D conforms to P, and it's documented that If a conforming type provides its own implementation of a required method or property, that implementation will be used instead of the one provided by the extension. It isn't used.3. If you put a definition of p in class C, then that implementation *is* used instead of the one provided by the extension. By what mechanism? It's not regular inheritance (again, there's no need of an 'override' keyword, which real inheritance would require, and it works for structs w

Have an existing Watchkit 1.x app and added 2.0 targets as mentioned by others. To use simulator of b3, we set project deployment target to 9.0, app deplyoment target to 7.0. Don't see a way to change deployment targets for 1.x watch app and extension, so guessing they stay as they were (8.2). Fo Watch 2, don't see where to specify deployment target either, so guessing since they are 'new' they will inherit deployment target from overall project (9.0). This allows us to build/run in the Simulators to test new Watch 2 targets. Since we are aiming to deploy one app to the store (not one for each ios version), we have Base SDK set as follows:Main app, 1.x watch app and extension set to Latest IOS (IOS9). 2 watch app and extension set to Latest Watch OS (watch OS2).We have not tried to build/run for earlier versions (1.x) using this beta. Really using this setup to test watch 2 but with all code/targets together.

Yes is does. It inherits NSObject and HKWorkoutSessionDelegate. The code was all working fine just yesterday, and after upgrading to xCode beta 4, I get errors on this code.

I think the current syntax using final and override are fine. The reason is as follows. If you've made the decision to define a new class, most likely it is because, you are designing for inheritence or you are inheriting another class you need which may or may not be from Objective-C which has no concept of final classes. So, most likely you are using classes because you have made a decision that you need or want to embrace inheritance. With that decision comes the responsibility to manage inheritance which means deciding what is final and what is accessible.By default, classes, methods and properties have internal access. With whole module optimization, you get much of the benefit that you would get by marking members final when using internal access which is the default. Where things matter most from a safety and performance perspective is when you choose to make a class or member public. In doing so, you must take responsibility to decide whether to mark it final or not

I don't think it's a bug, but the combination of a subtyping constraint and a type assignment is strange because the subtyping part (type-inheritance-clause_opt) is superfluous in this case.Here's some code showing the various alternatives. Type alias assignments are most useful to instantiate abstract associated types.protocol Buffer { typealias Element var value: Element { get } } protocol EquatableBuffer: Buffer, Equatable { // Constraining Element type typealias Element: Equatable } protocol IntBuffer: Buffer { // Instantiating Element type typealias Element = Int } protocol SuperfluousIntBuffer: Buffer, Equatable { // Not sure about the usefulness of this typealias Element: Equatable = Int }

> Has @objc suddenly been deprecated in favour of inheriting from NSObject?Pretty much yes. @objc on Swift-rooted classes never quite behaved like an NSObject-rooted class, leading to various weirdness in the generated header and at runtime. You can still treat any Swift class instance as an AnyObject, mark methods and properties on a Swift class as @objc, and conform to Objective-C protocols; the class just isn't exposed in the generated header and doesn't default to having its members available in Objective-C.(And we should update the book. Thanks for catching that!)

And, not an issue which could be causing sampleArray to not to be recognized, but...You are also setting the 'title' parameter inherited from UIViewController(var title: String? // Localized title for use by a parent controller.)instead of using a local variable.Is this what you intended?let title = sampleArray[indexPath.row] as StringAlso, there is a runtime issue you haven't hit yet if your code won't compile, but if the table is visible it will probably be asking for the data using tableView:cellForRowAtIndexPath: before tableView:didSelectRowAtIndexPath: is called and you will get a runtime exception because the array is still empty and tableView:numberOfRowsInSection: is saying there are 10 rows.If you want to fill your array with placeholder data, doing it in viewDidLoad() will make sure it is available for the other methods.