2015-03-26 10 views
5

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"); 
         ^~~~~~~~ 

risposta

0

sguardo al listed implementors of AsRef nella documentazione in modo più dettagliato e si scopre che c'è un altro implementazione che si scontra lì: impl<T> AsRef<[T]> for [T]. Quindi non può decidere se v.as_ref() deve essere di tipo &str o &[Ascii].

+0

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

+0

@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. –

+1

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

Problemi correlati