Would I run into any problems with having protocols with shared requirements?

Question

protocol House {
    var name : String {get set}
    func changeAddress()
}

protocol Person {
    var name : String {get set}
    func changeAddress()
}

class Something : Person, House {
    var name : String

    init (name: String){
        self.name = name
    }
    func changeAddress(){

    }
}

Likely I'm not going to do anything like this. But I'm asking this question because I'm getting no warning or anything for this. Isn't this a bug? ie the protocol witness table is conforming to two requirements through one conformance and it's hiding some of its variables, had I just changed the variable to something id on one of the protocols then the requirements would have been different, doesn't this at least merit a warning? and then maybe having it silenced by something like @sharedPWT :D

Isn't this code smell in it's nature? Or there are circumstances where this can actually be helpful?

Answer 1

Your witness table idea is a red herring because there is no code and no dispatch. It’s much simpler than that. Both protocols are merely instructions on how to construct an adopting type; they say “do this” and in your adopter you do that, so you conform to both requirements. No problem.

If these were methods with extensions and implementations, now we’d have something to talk about! For example:

protocol A {
    func f()
}
extension A {
    func f() { print("A")}
}
protocol B {
    func f()
}
extension B {
    func f() { print("B")}
}
class C:A,B {} // compiler stops you, rightly

Isn't this code smell in it's nature? Or there are circumstances where this can actually be helpful?

It’s not a bad smell, and in fact in a very real sense this kind of thing happens all the time throughout the standard library. After all, what's the protocol hierarchy but an example of the very thing you're outlining? To say that protocol P2 adopts protocol P1 is just a shorthand for saying that whatever P1 requires, P2 also requires.