Fehler bei der Verwendung von Self in generische Funktion where-Klausel

Question

Ich bin in einem Problem, wenn ich versuche, Self als Teil einer where Klausel in einer generischen Funktion, die Teil eines Protokolls ist zu verwenden.

Zum Beispiel sagen, ich habe dieses Protokoll und diese generische Funktion definiert:

protocol Animal { 
    associatedtype FoodSource 
    func eat(_ food:FoodSource) 
} 

// The where clause specifies that T2 must conform to 
// whatever type is T1's FoodSource associated type 
func feed<T1: Animal, T2>(animal:T1, food:T2) where T2 == T1.FoodSource { 
    animal.eat(food) 
} 

Der Funktion-Feed verwendet die klammert Aussage zu erklären, dass der erste Parameter mit dem Animal Protokoll entsprechen. Es verwendet die -Klausel, um zu deklarieren, dass der Typ des zweiten Parameters dem zugeordneten Typ des ersten Parameters entsprechen muss.

Es ist möglich, Klassen zu erstellen, die den Anforderungen dieser generischen Funktion entsprechen und alles funktioniert perfekt. Zum Beispiel:

protocol Meat {} 
protocol Vegetable {} 

class Rabbit : Animal { 
    typealias FoodSource = Vegetable 
    func eat(_ food:FoodSource) { 
     print("the Rabbit ate the \(type(of:food))") 
    } 
} 

class Lion : Animal { 
    typealias FoodSource = Meat 
    func eat(_ food:FoodSource) { 
     print("the Lion ate the \(type(of:food))") 
    } 
} 

class Carrot : Vegetable {} 
class Steak : Meat {} 
class ChickenSalad : Meat, Vegetable {} 

// works because Carrot conforms to Vegetable 
// prints: "the Rabbit ate the Carrot" 
feed(animal: Rabbit(), food: Carrot()) 

// works because Steak conforms to Meat 
// prints: "the Lion ate the Steak" 
feed(animal: Lion(), food: Steak()) 

// works because ChickenSalad conforms to Meat 
// prints: "the Lion ate the ChickenSalad" 
feed(animal: Lion(), food: ChickenSalad()) 

// works because ChickenSalad conforms to Vegetable 
// prints: "the Rabbit ate the ChickenSalad" 
feed(animal: Rabbit(), food: ChickenSalad()) 

So weit so gut.

Allerdings, wenn ich das gleiche Muster von Generika im Rahmen eines Protokolls implementieren, ist es nicht mehr funktioniert:

protocol Food { 
    func feed<T:Animal>(to:T) where Self == T.FoodSource 
} 

extension Food { 
    func feed<T:Animal>(to animal:T) where Self == T.FoodSource { 
     animal.eat(self) 
    } 
} 

class SteakSalad : Food, Meat, Vegetable {} 

SteakSalad().feed(to: Lion()) 

Wenn er ausgeführt wird, wird dieser Block den folgenden Fehler führt:

error: generic parameter 'T' could not be inferred 
SteakSalad().feed(to: Lion()) 
      ^

Ist Gibt es einen Weg, das gewünschte Verhalten zu erreichen?

Answer 1

Bevor Sie dies diskutieren, rate ich Ihnen dringend, Ihr Problem zu überdenken und Ihre Typen zu vereinfachen. Sobald Sie in Swift die Straße des Mischens von Generika und Protokollen durchlaufen haben, werden Sie das Typsystem nonstop bekämpfen. Ein Teil davon ist, dass komplexe Typen komplex sind und es schwierig ist, sie selbst mit einem sehr starken Typsystem korrekt zu machen. Ein Teil davon ist, dass Swift kein sehr starkes Typsystem hat. Verglichen mit Objective-C oder Ruby ist es zwar unglaublich mächtig, aber es ist immer noch ziemlich schwach um generische Typen und es gibt viele Konzepte, die man nicht ausdrücken kann (es gibt keine höher-kinierten Typen, es gibt keine Möglichkeit Kovarianz oder Kontravarianz auszudrücken) , keine abhängigen Typen, und es gibt komische Macken, wie Protokolle nicht immer mit sich selbst übereinstimmen). In fast allen Fällen, in denen ich mit einem Entwickler an ihren komplexen Typen gearbeitet habe, stellte sich heraus, dass ihr tatsächliches Programm nicht so viel Komplexität erforderte. Protokolle mit zugehörigen Typen sollten als ein fortgeschrittenes Werkzeug betrachtet werden; Greife nicht nach ihnen, außer du brauchst sie wirklich. Weitere Informationen hierzu finden Sie unter Beyond Crusty.

Das funktioniert nicht, weil es Ihre where Klausel verletzt:

func feed<T:Animal>(to:T) where Self == T.FoodSource 

So Animal.FoodSourceSelf übereinstimmen muss. Schauen wir uns an, wie Sie es verwenden:

SteakSalad().feed(to: Lion()) 

So Self ist SteakSalad und Lion.FoodSourceMeat ist. Diese sind nicht gleich, so dass dies nicht gilt. Was Sie wirklich meinen, ist dies:

func feed<T:Animal>(to animal:T) where Self: T.FoodSource 

Aber das ist nicht legal Swift („error: erster Typ‚T.FoodSource‘in Übereinstimmung Anforderung bezieht sich nicht auf einen generischen Parameter oder zugehörigen Typen“). Das Problem ist, dass T.FoodSource alles sein könnte; es muss kein Protokoll sein. "Selbst entspricht einem beliebigen Typ" ist Swift nicht sinnvoll.

Wir könnten versuchen, dies zu verbessern, indem sie zu FoodFoodSource zumindest entsprechen zu machen, aber es kommt noch schlimmer:

protocol Food {} 
protocol Meat: Food {} 

protocol Animal { 
    associatedtype FoodSource: Food 
} 

Und dann Lion machen essen Fleisch:

class Lion : Animal { 
    typealias FoodSource = Meat 

MyPlayground.playground:1:15: note: possibly intended match 'Lion.FoodSource' (aka 'Meat') does not conform to 'Food'

typealias FoodSource = Meat

Doesn 't Fleisch entspricht dem Essen? Hah, nein. Dies ist Teil der größeren Einschränkung "Protokolle entsprechen sich nicht selbst" in Swift. Sie können Protokolle nicht einfach so behandeln, wie sie Vererbung haben. Manchmal tun sie das und manchmal nicht.

Was können Sie tun, ist, dass das Fleisch zu Fleischesser eingespeist werden kann:

protocol Meat {} 

extension Meat { 
    func feed<T:Animal>(to animal:T) where T.FoodSource == Meat { 
     animal.eat(self) 
    } 
} 

Und Veg gefüttert werden können, um veg-Esser:

protocol Vegetable {} 

extension Vegetable { 
    func feed<T:Animal>(to animal:T) where T.FoodSource == Vegetable { 
     animal.eat(self) 
    } 
} 

Aber es gibt keinen Weg, ich weiß um dies generisch über Protokolle mit assoziierten Typen (PATs) zu machen. Es ist einfach zu viel für das Swift-System. Meine Empfehlung ist, die PAT loszuwerden und nur Generika zu verwenden. Die meisten dieser Probleme werden verschwinden. Sogar in einer Sprache wie Scala, die ein leistungsfähigeres Typsystem und auch verwandte Typen hat, ist die richtige Antwort in der Regel einfachere Generika (und oft nicht einmal das; wir machen Dinge oft generisch, wenn es nicht nötig ist).