Declaring Conformance to @Objc Protocol in Empty Extension Breaks with Exc_Bad_Instruction

How can I get conditional protocol conformance with a protocol's parent?

The question as posed, "How can I get conditional protocol conformance with a protocol's parent?" is meaningless, because a protocol always conforms with its parent; there is no "conditional" about it.

As for your actual code, the problem is the phrase A<Resource>. Saying A<Resource> is not a correct resolution of A's T. You need to resolve T as a class, struct, or enum — not as a protocol.

For example, if you have a class B that conforms to Resource, you can declare

let a = A<B>()

and all is well.

if there was a way to let A<Resource> know that it will always be working with concrete types that conform to Codable

Well, as I said, your code compiles fine as soon as A is working with a concrete type that does conform to Codable. So if that's what A will always be working with, there's nothing more to do. You could of course tell A that its T will always conform to Resource (which by definition will always conform to Codable):

class A<T:Resource> {}

Adding delegate protocol conformance to pure swift class

One of possible options is to make a separate class MyHome, which implements HMHomeManagerDelegate, and then use it inside of class B.

class MyHome: NSObject, HMHomeManagerDelegate { ... }

class B: A {
    let myHome = MyHome()

    // and all communication with HomeKit will go through MyHome class
    // ...
}

If your project is small, I guess MyHome will look like a useless wrapper. But in a bigger application I can imagine that MyHome is responsible for convenient communication with HomeKit, so class B makes decisions while MyHome serves it (prepares/modifies some data which goes to/from HomeKit).

Can I add protocol conformance to `UnsignedInteger` via extensions on those protocols?

Look at what you have written here:

//                                           vvvvvvvvvvvvvvvvvvvv
public extension JSONStringConvertible where Self:UnsignedInteger

The extension only applies to unsigned integers! Is Int an unsigned integer? No! Int is a signed integer while UInt is unsigned.

So just change Unsigned to Signed and then make extensions on Int, Int64, Int32 etc. e.g.

extension Int: JSONStringConvertible, JSONSerializable {}
extension Int32: JSONStringConvertible, JSONSerializable {}
extension Int64: JSONStringConvertible, JSONSerializable {}

Also, you would have to add other protocol extensions where Self:UnsignedInteger, so all your protocol extensions will look like this:

extension JSONSerializable where Self:SignedInteger, Self:JSONStringConvertible
{
    var jsonObject: JSONStringConvertible { return self }
}
extension JSONStringConvertible where Self:SignedInteger
{
    var jsonString: String { return "" }
}

extension JSONSerializable where Self:UnsignedInteger, Self:JSONStringConvertible
{
    var jsonObject: JSONStringConvertible { return self }
}
extension JSONStringConvertible where Self:UnsignedInteger
{
    var jsonString: String { return "" }
}

Issue with protocol conformance in Swift using associatedtype

You should define your classes DummyProducer and DummyConsumer like this:

class DummyProducer: Producer {
    typealias T = EmptyItem

    func registerConsumer<C: Consumer where C.T == T>(consumer: C) {

    }
}

class DummyConsumer: Consumer {
    typealias T = EmptyItem

    func consume<P: Producer where P.T == T>(producer: P, item: T) {

    }
}

Since you strictly specified associatedType T to be ItemType in protocol definition, you weren't able to use only EmptyItem in your classes because EmptyItem is not the only structure that can adopt ItemType protocol.

Creating an array of @objc protocol type from arrays of conformers

After generating a bunch of code that's missing here, I come up with the following that seems to work as you expect:

import Foundation

@objc protocol Utterable {}
@objc protocol Displayable {}
@objc protocol Departure {}

typealias Presentable = protocol<Utterable, Displayable, Departure>
typealias TableSection = (sectionTitle: String, rows: [Presentable])

class Bus : Presentable {}
class Metro : Presentable {}
class Train : Presentable {}
class Tram : Presentable {}
class Ship : Presentable {}

let buses : [Bus]? = nil
let metros : [Metro]? = [ Metro() ]
let trains : [Train]? = [ Train() ]
let trams : [Tram]? = nil
let ships : [Ship]? = [Ship()]

let departments : [[Presentable]?] = [ buses, metros, trains, trams, ships]

// filter out the non-nil departments that actually have elements
let acceptable = departments.filter { $0?.count > 0 }

// map the acceptable departments into sections, note that we force-unwrap
//  dept because we already verified in the step above that it must be
//  valid
let sections : [TableSection] = acceptable.map { (sectionTitle:"test", rows: $0!) }

Note that this uses a couple of very important builtin functions filter and map I'd suggest really digging into them as they, plus reduce are incredibly powerful built-ins that almost eliminate the need to ever manually do your own array iteration.

Or, for compactness, you can use:

// or for compactness...
let sections2 : [TableSection] = departments.filter({ $0?.count > 0 })
                                            .map({ (sectionTitle:"test", rows: $0!) })

Swift: conforming to protocol using extension and composition pattern

Composition refers to "implementing" interfaces, in Swift called conforming to protocols.

On the other side of the fence is Inheritance where you extend classes.

The main problem here is that you can only extend one class but conform to as many interfaces as you wish (at least in Swift). Therefore if your class wants to be the UITableViewDelegate and UITableViewDataSource you can only achieve that with composition.

Interfaces/Protocols leave a lot more open to the developer in opposition to what classes can you. Protocols only define functions and methods - and in Swift properties, which have some function-like functionality themselves. Classes on the other hand can contain variables, constants etc. And they can implement some of them already - something that interfaces mostly cannot do.

---

Related Topics