Я вижу, что std::convert::Into имеет реализацию для всего, что реализует std::convert::From:
impl<T, U> Into<U> for T where U: From<T>
Есть гораздо более конкретные реализации From, тогда как Into в настоящее время имеет только 3 конкретных реализации, что делает его похожим на то, что по умолчанию принято внедрять From. Я уверен, что есть моменты, когда я хотел бы реализовать Into, а не From, но я их не вижу.
Интересно, что исходный RFC о std::convert указывает на противоположную оболочку:
impl<T, U> From<T> for U where T: Into<U>
Но на PR, реализующем его, было изменено на противоположное:
Добавлена реализация
From= >Into, которая позволяет добавлять конверсии в обоих направлениях без нарушения согласованности. Например, теперь мы имеемFrom<[T]> for Vec<T> where T: Clone, что дает соответствующее Into движение в другом направлении - несмотря на то, что два типа живут в разных ящиках.Я также считаю, что это затрагивает несколько проблем, связанных с реализацией From вместо Into
Невозможно сделать a impl<'a, T> Into<Foo> for &'a [T], тогда как impl<'a, T> From<&'a [T]> for Foo возможно.
Первая попытка вызывает a E0210:
error: параметр типа
Tдолжен использоваться как параметр типа для некоторого локального типа (например,MyStruct<T>); только черты, определенные в текущем ящике, могут быть реализованы для параметра типа
Но это изменение в последний момент отражает, что From и Into в основном эквивалентны. From был выбран как предпочтительный, поскольку он был менее ограничительным с точки зрения типа "тип против локального типа".
В стандартной библиотеке есть только два примера реализации Into, а не From:
impl Into<Vec<u8>> for String
impl Into<OsString> for PathBuf
Но они, я думаю, отражают логику их интерфейсов. OsString реализует From<String> и From<T> where T: AsRef<OsStr>, потому что это естественные вещи, которые вы хотите построить OsString из.
Однако PathBuf все еще реализует Into<OsString> как обратную операцию реализации From<OsString>, но эта логика принадлежит PathBuf, а не OsString.