2015-03-26 14 views
5

Używam nowych ogólnych cech konwersji w moim kodzie i doświadczam zmniejszonej ergonomii. Ten kod implementuje AsRef<str> for [Ascii], jak widać w przykładzie.Adnotacja typu wymagana podczas używania `as_ref()` w `assert_eq!()`

Teraz chcę użyć v.as_ref() w assert_eq!() i oczekiwać, że v.as_ref() zwraca &str za pomocą dostarczonego realizację ponieważ drugi argument assert_eq!() jest typu &str.

Nie ma implementacji AsRef<String> for [Ascii], więc moim zdaniem w grę wchodzi tylko jedna implementacja PartialEq: PartialEq<str> for &str.

Kompilator nie stosuje się do moich wyjaśnień i narzeka na adnotacje typu wymaganego. Jak mogę uniknąć wyraźnej adnotacji i dlaczego kompilator nie może znaleźć prawidłowej implementacji AsRef<_>?

Dzięki

#![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"); 
} 

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

Odpowiedz

0

Spójrz na listed implementors of AsRef w dokumentacji w sposób bardziej szczegółowy i można zauważyć, że istnieje inna realizacja, która zderza się tam: impl<T> AsRef<[T]> for [T]. Więc nie może zdecydować, czy v.as_ref() powinien być typu &str lub &[Ascii].

+0

Dlaczego porównanie z znaną propozycją przewodnika pomocniczego 'i str' nie jest znane? Odtwarzając niektóre niestandardowe implementacje 'AsRef' z wieloma typami docelowymi, wnioskowanie typu wydaje się rozumieć" inny typ "i używać go do usuwania niejednoznaczności. – Shepmaster

+0

@Shepmaster: 'assert_eq' robi pewne dziwaczne rzeczy, które mają w przeszłości trochę kłopotów z wnioskiem, a zmiany w ciągu ostatnich kilku dni spowodowały mały problem. Mam nadzieję, że tego rodzaju sprawa zostanie rozwiązana w najbliższej przyszłości, choć na pewno nie mogę jej zagwarantować. –

+1

Ale [nadal nie działa z bezpośrednim porównaniem równości] (http://is.gd/O5WgsJ), co powoduje, że myślę, że istnieje druga implementacja, która gdzieś gdzieś jest bardziej konfliktowana. Jednak widzę również, że czasami [* order * of items] (http://is.gd/UwBrBU) wpływa na wnioskowanie typu, co wydaje się być błędem, więc to zapiszę. – Shepmaster