Das Muster, ob eine objektsichere Eigenschaft Foo und eine (potentiell unsichere) Erweiterungseigenschaft FooExt für alle Instanzen von Foo implementiert wurde, scheint nun Standard zu werden.
Das ist ein Problem für mich im Fall von Iterator<A> , da ich eine Bibliothek habe, die die Standardmethode IteratorExt#last() des alten Iteratormerkmals überschreibt (die zugrunde liegende Bibliothek hat eine effiziente Implementierung von last() ). Dies ist nun unmöglich, weil für jede A immer eine widersprüchliche Eigenschaften-Implementierung von IteratorExt vorhanden ist, die libcore bereits für alle Iterator<A> bereitstellt.
iterator.rs:301:1: 306:2 error: conflicting implementations for trait 'core::iter::IteratorExt' [E0119]
Nun, soweit ich das sehe, habe ich zwei Möglichkeiten:
last() Implementierung. Das würde bedeuten, dass es Konflikte gibt, wenn IteratorExt importiert wird, es sei denn, es wird sorgfältig verwendet. Dies hat auch die Gefahr, dass versehentlich eine ineffiziente Version von last() verwendet wird, wenn die Version von IteratorExt verwendet wird. Ich würde den bequemen Zugang zu IteratorExt verlieren. seek_last() ). Nachteil: Ich bitte den Benutzer, Vokabeln zu lernen und meine Methode immer gegenüber der von IteratorExt zu bevorzugen. Gleiches Problem: Ich möchte die versehentliche Verwendung von last() vermeiden. Gibt es noch eine andere, bessere Lösung, die mir fehlt?
Ab rustc 0.13.0-nightly (8bca470c5 2014-12-08 00:12:30 +0000) defining last() als inhärente Methode für Ihren Typ sollte funktionieren.
Da Sie keine Extension-Merkmale als generische Grenzen verwenden sollen (sondern nur um zusätzliche Methoden bereitzustellen), sollte dies theoretisch für Ihr Szenario funktionieren, da Sie Ihren eigenen Typ und seine impl in derselben Kiste haben können.
Benutzer Ihres Typs verwenden die inhärente Methode last anstatt der Methode IteratorExt , können aber weiterhin die anderen Methoden für IteratorExt verwenden.
last sollte in Iterator anstatt in IteratorExt verschoben werden.
IteratorExt wird benötigt, wenn Box<Iterator> -Objekte verwendet werden, um den Aufruf generischer Methoden zu ermöglichen (z. B. map ), weil Sie keine generische Methode in eine vtable einfügen können. % Co_de% ist jedoch nicht generisch, daher kann es in last eingefügt werden.