§ From を実装すべき状況

From の実装を使って行える変換に技術的制約はないが、一般的な期待としては変換はおおむね以下のように制限される。

• 変換は失敗しない : もし変換が失敗しうるなら、代わりに TryFrom を使え; パニックする From を提供するな。

• 変換は無損失である : 意味論として、情報を失ったり破棄したりすべきでない。例えば、i32: From<u16> があり、そこでは元の値は u16: TryFrom<i32> を使って復元できる。また、String: From<&str> があり、そこでは元の値と同等のものが Deref 経由で取得できる。しかし、From は u32 から u16 への変換には使えない、なぜならこれは無損失な方法では達成できない。(ここで意味論に関係ない情報については余地がある。例えば、Box<[T]>: From<Vec<T>> では、容量が違っても二つのベクターが等しくなりうるように、容量を維持しないかもしれない。)

• 変換は値を維持する : Rust の型や技術的表現が異なっても、概念的な種類と結果値の意味は同じになる。例えば、as でキャストを戻せば元の値を復元できるため、-1_i8 as u8 は無損失だが、-1 と 255 は概念的に異なる値なため (技術的には同じビットパターンだが) その変換は From を通しては利用できない。ただし f32: From<i16> は 1_i16 と 1.0_f32 は概念的に同じ実数なため (技術的には完全に異なるビットパターンだが) 利用できる。String: From<char> はどちらもがテキストなので利用できるが、String: From<u32> は 1 (数) と "1" (テキスト) があまりに異なるため利用できない。(値のテキストへの変換は代わりに Display トレイトによりカバーされる。)

• 変換は明確になる : それは二つの型の間の唯一の合理的変換である。そうでなければ、str::as_bytes がメソッドであるように、また整数がメソッド u32::from_ne_bytes, u32::from_le_bytes, そして u32::from_be_bytes を持ち、そのどれもが From を実装していないように、名前付きのメソッドやコンストラクタを持った方が良い。一方で Ipv6Addr を IpAddr にラップするには唯一の合理的な方法があり、そのため IpAddr: From<Ipv6Addr> がある。