Traits

Add Trait: Typenparameter vs. assoziierter Typ

Erinnern Sie sich an die Definition des Add-Traits:

trait Add<Rhs=Self> {
    type Output;
    fn add(self, rhs: Rhs) -> Self::Output;
}

Welche der folgenden Aussagen beschreibt am besten, warum Output ein assoziierter Typ ist, während Rhs ein Typenparameter ist?

1. Die add-Operation nimmt Rhs als Eingabe und erzeugt Output als Ausgabe, und Typenparameter werden für die Eingabe verwendet, während assoziierte Typen für die Ausgabe verwendet werden.

2. Ein Typ T sollte zu vielen anderen Typen S addierbar sein, aber eine gegebene T + S-Operation sollte immer einen einzigen Ausgabetyp haben.

3. Ein assoziierter Typ kann keinen Standardwert haben, während ein Trait-Typenparameter einen Standardwert haben kann.

4. Ein Trait kann nur einen einzigen assoziierten Typ haben, daher muss Rhs ein Typenparameter für Add sein.

Prüfen

Es stimmt, dass ein assoziierter Typ derzeit keinen Standardwert haben kann, aber das ist nicht der Hauptgrund, warum Rhs ein Typenparameter im Add-Trait ist.

---

Add Trait: Typenparameter-Position

Erinnern Sie sich an die Definition des Add-Traits:

trait Add<Rhs=Self> {
    type Output;
    fn add(self, rhs: Rhs) -> Self::Output;
}

Welche der folgenden Aussagen beschreibt am besten, warum Rhs ein Typenparameter des Traits Add und nicht der Funktion add ist? Das heißt, warum ist Add nicht so konzipiert:

trait Add {
    type Output;
    fn add<Rhs>(self, rhs: Rhs) -> Self::Output;
}

1. Der Typ-Checker arbeitet effizienter, wenn Rhs ein Typenparameter auf Trait-Ebene ist als ein Typenparameter auf Funktionsebene.

2. Wenn Rhs ein Typenparameter auf Funktionsebene wäre, könnte die Definition von add keine Struktur für Rhs annehmen.

3. Die Codegenerierung für die add-Funktion würde aufgrund des Typenparameters auf Funktionsebene zusätzliche Zeit für die Monomorphisierung erfordern.

4. Rhs kann keinen Standardtyp als Typenparameter auf Funktionsebene haben.

Prüfen

Ein solches Design würde wenig Sinn ergeben, da add<Rhs> keine Informationen über die Struktur von Rhs hätte, sodass es unmöglich wäre, auf diese Weise eine sinnvolle Additionsfunktion zu implementieren.

---

Trait-Methoden-Auflösung

mod inner {
    pub trait A {
        fn f(&self) -> usize { 0 }
    }
    pub trait B {
        fn f(&self) -> usize { 1 }
    }
    pub struct P;
    impl A for P {}
    impl B for P {}
}
fn main() {
    use inner::{P, B};
    println!("{}", P.f());
}

1. Kompiliert
2. Kompiliert nicht

Prüfen

Wenn nur eine von zwei widersprüchlichen Trait-Implementierungen importiert wird, verwendet Rust die importierte Implementierung. Vollqualifizierte Syntax ist hier nicht notwendig.

---

Newtype für Trait-Implementierung

Stellen Sie sich vor, Sie implementieren einen Trait Trait für einen Typ T. In welcher der folgenden Situationen müssen Sie T in einen Newtype verpacken?

1. Trait ist in einer externen Krate definiert und T ist in einer externen Krate definiert.

2. Trait ist in der lokalen Krate definiert und T ist in der lokalen Krate definiert.

3. Trait ist in der lokalen Krate definiert und T ist in einer externen Krate definiert.

4. Trait ist in einer externen Krate definiert und T ist in der lokalen Krate definiert.

Prüfen

Die Orphan-Regel besagt, dass ein Trait nicht für einen Typ implementiert werden kann, wenn beide in einer externen Krate definiert sind, was einen Newtype erforderlich macht. Wenn entweder der Trait oder der Typ lokal definiert sind, ist ein Newtype unnötig.

---