Sto utilizzando i nuovi tratti di conversione generici nel mio codice e l'ergonomia ridotta. Il codice in questione implementa AsRef<str> for [Ascii]
come si può vedere nell'esempio.È richiesta l'annotazione del tipo quando si utilizza `as_ref()` in `assert_eq!()`
Ora voglio usare v.as_ref()
in assert_eq!()
e si aspettano che v.as_ref()
restituisce un &str
usando l'implementazione prevista perché il secondo argomento di assert_eq!()
è di tipo &str
.
Non esiste un'implementazione di AsRef<String> for [Ascii]
quindi a mio parere solo una implementazione di PartialEq
entra in gioco: PartialEq<str> for &str
.
Il compilatore non segue la mia spiegazione e si lamenta delle annotazioni del tipo richieste. Come posso evitare l'annotazione esplicita e perché il compilatore non può capire l'implementazione corretta di AsRef<_>
?
Grazie
#![feature(convert)]
struct Ascii { chr: u8 }
impl AsRef<str> for [Ascii] {
fn as_ref(&self) -> &str {
unsafe { ::std::mem::transmute(self) }
}
}
fn main() {
let v = [Ascii { chr: 65 }, Ascii { chr: 66 }];
assert_eq!(v.as_ref(), "AB");
// Workaround: explicit type annotation.
//assert_eq!(AsRef::<str>::as_ref(&v[..]), "AB");
}
collegamento box: http://is.gd/ZcdqXZ
<anon>:15:18: 15:26 error: type annotations required:
cannot resolve `[Ascii] : core::convert::AsRef<_>` [E0283]
<anon>:15 assert_eq!(v.as_ref(), "AB");
^~~~~~~~
Perché il paragone con un'inferenza di tipo "& str" non è comparabile? Giocando con alcune implementazioni personalizzate di 'AsRef' con più tipi di destinazione, l'inferenza del tipo sembra comprendere" l'altro tipo "e usarla per rimuovere l'ambiguità. – Shepmaster
@Shepmaster: 'assert_eq' fa alcune cose un po 'funky che hanno una storia di confusione con l'inferenza un po', e le modifiche negli ultimi giorni, in particolare, hanno causato un piccolo problema. Speriamo che questo tipo di caso sarà risolto nel prossimo futuro, anche se certamente non posso garantirlo. –
Ma [non riesce ancora con un confronto diretto di uguaglianza] (http://is.gd/O5WgsJ), il che mi fa pensare che ci sia una seconda implementazione che confligge più direttamente da qualche parte. Tuttavia, vedo anche che a volte il [* ordine * degli elementi] (http://is.gd/UwBrBU) influenza l'inferenza di tipo, che sembra un bug, quindi lo archivierò. – Shepmaster