Cloneを必要とせずに変換が失敗した場合に、元の値でエラーを一般的に出力する方法はありますか？失敗するとパニックになる関連メソッドに適切なエラーメッセージが表示される可能性がありますか？

これが前奏曲に入る必要があるかどうかの議論は、これが安定するときのために保留されています。

これがどこかでカバーされている場合はお詫びしますが、これを安定しているとマークする前に何を見たいですか？ さまざまなプロジェクトでこの機能を数回再実装したと確信しているので、一般的な再利用可能な特性により、私は😄

次のサイクルのためにそれを議論のために持ち出すことができます。

🔔この問題は現在、安定化のためにサイクルの長い最終コメント期間に入っています🔔

安定化のポイントとして、libsチームは、安定化の一環として、これらの特性をプレリュードに追加したいと考えています。 これには、クレーターの実行が_少なくとも_100％クリーンである必要がありますが、現在の解決の状態により、プレリュードに特性を追加するための下位互換性があると比較的確信しています。

これらの特性の目的についていくつか質問があります。

1. stdのどのタイプにこれらが実装されますか？
2. impl TryFrom<T> for Tのような実装を取得する必要があるタイプはどれですか？
3. すでにimpl From<U> for Tがある場合、どのタイプがimpl TryFrom<U> for Tのような実装を取得する必要がありますか？

cc @sfackler 、現在のimplのセットといくつかの理論的根拠についても拡張できますか？

変換が失敗する可能性がある場合を除いて、一般的に、直感はFrom / Intoの直感とまったく同じである必要があると思います。 FromとIntoの実装を標準ライブラリタイプに徐々に追加するのと同じように、 TryFromとTryIntoでも同じことを行うと思います。 ここで最も重要なガイドラインは、変換は「標準的に明白な」ものでなければならないということです。あるタイプを別のタイプに変換する合理的な方法が複数ある場合、 TryFromまたはFromは正しくない可能性があります使用するもの。

_一般的に_、すべてのタイプがimpl TryFrom<T> for Tであるとか、手動でimpl From<U> for Tを持ち上げる必要があるとは思わない。 特に、どのエラータイプを選択するかが明確でないことがよくあります。 ただし、これらの種類の実装は、特定のAPIを機能させるために定義でき、定義する必要がある実装です。 たとえば、RFCで概説されている理由により、プリミティブ整数型のさまざまな組み合わせに対して、これらの種類の実装が両方ともあります。 別の例として、 TryFrom / TryIntoが置き換えるアドホックな特性の1つは、 postgres :: IntoConnectParamsです。これには、 ConnectParamsをそれ自体に変換する再帰的な実装があります。

一般に、すべてのタイプがTryFrom<T> for Tを実装したり、手動でimpl From<U> for Tを持ち上げたりする必要があるとは思われません。

TryFromの変換が間違いない場合、エラータイプはenum Void {}であるはずですよね？ （または他の名前の同様の列挙型。）ちなみに、これは、汎用のVoidをstdと入力する正当な理由のように思えます。

@SimonSapinは、 IntoConnectParamsスタイルのAPIと、RFCで概説されている整数変換のユースケースを破ります。これは、間違いのない変換と間違いのない変換のエラータイプが一致しないためです。

@SimonSapin https://github.com/rust-lang/rfcs/pull/1216

@sfacklerエラータイプ（例： try! ）にプレーンなFromを使用する場合は違います！ impl<T> From<!> for Tは、その目的のために存在することができ、存在する必要があります。

FromとIntoの実装を標準ライブラリタイプに徐々に追加するのと同じように、 TryFromとTryIntoでも同じことを行うと思います。

それはまだ起こっていないようですので、誰もそれに近づいていないのか、 stdに該当するタイプがないのかはわかりません。 stdに該当するタイプがある場合は、それらのいくつかの実装を確認するとよいでしょう。 たとえば、次の優れた実装のいずれかですか？

impl TryFrom<u32> for char
impl TryFrom<char> for u8
impl TryFrom<Vec<u8>> for String
impl TryFrom<&[u8]> for &str

_一般的に_、すべてのタイプがimpl TryFrom<T> for Tであるとか、手動でimpl From<U> for Tを持ち上げる必要があるとは思わない。

問題は、 TryInto<T>を使用したいが、 Tがクレートにない場合は、 impl TryFrom<T> for Tが実装されていることを期待する必要があるということです。 これは残念な制限であり、 From / Intoには存在しません。

@SimonSapinは、 IntoConnectParamsスタイルのAPIと、RFCで概説されている整数変換のユースケースを破ります。これは、間違いのない変換と間違いのない変換のエラータイプが一致しないためです。

これは、変換先のタイプに基づいてエラータイプが何らかの形で修正されることを意味しますか？

TryFrom::ErrとTryInto::Errがstd::error::Errorに制限されないのはなぜですか？

std :: error :: Errorに制限されていませんか？

これにより、 Errが()になるのを防ぐことができます。これは、間違いのない変換の実行可能なエラータイプです。

()がエラータイプの場合、関数はErr(())を返す可能性があります。 これは、関数を確実にするものではありません。 失敗しても、有用なエラーを提供できません。 失敗するかもしれないし、失敗しないかもしれない変換を使用するコードを書くとき、私は最良の方法はIntoに縛られ、$ TryIntoを使用する特殊化を書くことだと思います。

RFC 1216が実装されると、 !が間違いのない変換に適したエラータイプになります。 私は、 TryFrom::Err / TryInto::Err $にバインドされた$ ErrorがOKであることを意味すると思います。

From<T>実装することでTryFrom<T, Err = !>の実装が得られれば（もちろん、 Intoも同様です）、私は確かにそれを望んでいます。

私は、 TryFrom::Err / TryInto::Err $にバインドされたErrorがOKであることを意味すると思います。

はい、まさにこの種のケースには間違いなくimpl Error for ! { ... }があります。

整数変換のユースケースでの型の違いについて少し心配していますが、 ! -as-a-typeが着陸して実験する機会が得られるまで、これを安定させる必要があるようです。

私のPOVでは、エラーを表すすべての関連するタイプはErrorで囲まれている必要があります。 残念ながら、私たちはすでにそれなしで1つのタイプを残しました： FromStr::Err （他のパブリックタイプはTryIntoとTryFromのみで、 ack 'type Err;'とack 'type Error;'でチェックされます

最近議論されたように、libsチームは、 !タイプが解決されるまで、これらの特性を安定させることにパントすることを決定しました。

これはもうブロックされていないと思いますよね？

@sfacklerとして指名を削除すると、 !タイプとこれらの特性が調査されます。

近い将来、これは安定するための変更がありますか？

TryFrom :: ErrとTryInto :: Errがstd :: error :: Errorに制限されないのはなぜですか？

std::err::Errorは#![no_std]ビルドには存在しません。 また、多くの場合、エラータイプが利用可能であっても、 std::err::Errorを実装してもメリットはありません。 したがって、私はそのような限界を持たないことを望みます。

私はこれを自分のライブラリに実装することを試みました。 https://github.com/rust-lang/rfcs/pull/1542#issuecomment -206804137で@SimonSapinが表明した懸念を繰り返したいと思います。「try」という言葉は混乱しているため、 try!(x.try_into());は混乱を招きます。同じステートメントで2つの異なる方法を使用しました。

多くの人がそのようなことをx.try_into()?;と書くべきだと理解していますが、私は（すべての議論に基づいて） ?構文を使用しないことを強く好むかなりの数の人々の1人ですなぜなら...すべての議論で言及されたすべての理由。

個人的には、名前にtry_プレフィックスを必要としないパターンを見つけるように努めるべきだと思います。

ネーミングについては特に強くは感じませんが、個人的にはこれ以上良いものは考えられません。

Resultを返す関数のフレーバーにtry_を使用することは、すでに半標準になっています。

しかし、私は（すべての議論に基づいて）かなりの数の人々の1人であり、すべての議論で言及されているすべての理由のために、 ?構文を使用しないことを強く望んでいます。

その議論はもう終わったのではないですか？ つまり、私は議論のその側面に同情します：なぜ人々がtry!()をとても迷惑だと言ったのかわかりません、 ?は目立たず、怠惰なエラー処理を助長しているようですすでに完全に優れたマクロを持っていたものの構文の無駄（将来、より一般的なものになるように拡張されない限り）。

しかし、それは過去のことです。 ?は安定していて、消えることはありません。 したがって、全員が同じものを使用し、 try!との名前の競合について心配するのをやめることができるように、全員がそれに切り替えることもできます。

rust-lang / rfcs＃1542（コメント）で@SimonSapinによって表明された懸念を繰り返したいと思います

私は名前で引用されているので、私はもうそれほど心配していません。 私がこのコメントをしたとき、 ?演算子は将来が不確かな提案でしたが、今はここにとどまります。

また、バイクシェディングという名前の別のラウンドよりも、後者よりも早く安定させることが重要だと思います。 RFCが受け入れられてから数か月が経ち、これは#[unstable]に実装されました。

結果を返す関数のフレーバーにtry_を使用することは、すでに半標準になっています。

これは私がこの機能について最も奇妙だと思うことです。 私が作成するほとんどの関数はResultを返しますが、この特性を試してみる場合を除いて、これらの関数にtry_プレフィックスを付けたことはありません。

また、これを書くことの実際的な利点は見つかりませんでした。

impl TryInto<X> for Y {
    type Err = MyErrorType;

   fn try_into(self) -> Result<X, Self::Err> { ... }
}

代わりに、私はいつでもこれを書くことができ、構文上のオーバーヘッドははるかに少なくなります。

    fn into_x(self) -> Result<X, MyErrorType> { ... }

変換が多いにもかかわらず、 TryIntoまたはTryFromでパラメーター化されたジェネリックコードを作成する必要がなかったため、定義する型でのすべての使用には後者の形式で十分です。 TryInto<...>またはTryFrom<...>のパラメーターがあると、疑わしい形式のように思えます。

また、常にErrorと入力したため、関連するエラータイプに$ Error ＃$ではなくErrという名前を付けると、エラーが発生しやすくなることがわかりました。 この間違いは、RFC自体のドラフト中にも行われたことに気づきました： https：//github.com/rust-lang/rfcs/pull/1542#r60139383。 また、 Resultを使用するコードは、 Resultコンストラクターであるため、すでにErrという名前を広範に使用しています。

特に整数型に焦点を当て、「広げる」や「狭くする」などの用語を使用する別の提案がありました。たとえば、私も実装したx = try!(x.narrow());です。 組み込みの整数型でこのような変換を行うだけだったので、実際の使用法でここで提案された機能を使用するには、提案で十分であることがわかりました。 また、それで十分なユースケースでは、より人間工学的で明確な（IMO）です。

また、これを書くことの実際的な利点は見つかりませんでした...

私はある程度同意します。 この特性は、あるものを使用して別のものを作成できるが、そのプロセスが失敗する場合がある場合に使用します。ただし、これはほぼすべての関数のように聞こえます。 つまり、これらのimplが必要ですか？：

impl TryInto<TcpStream> for SocketAddr {
    type Err = io::Error;
    fn try_into(self) -> Result<TcpStream, io::Error> {
        TcpStream::connect(self)
    }
}

impl<T> TryInto<MutexGuard<T>> for Mutex<T> {
    type Err = TryLockError<MutexGuard<T>>;
    fn try_into(self) -> Result<Mutex<T>, Self::Err> {
        self.try_lock()
    }
}

impl TryInto<process::Output> for process::Child {
    type Err = io::Error;
    fn try_into(self) -> Result<process::Output, io::Error> {
        self.wait_with_output()
    }
}

impl TryInto<String> for Vec<u8> {
    type Err = FromUtf8Error;
    fn try_into(self) -> Result<String, FromUtf8Error> {
        String::from_utf8(self)
    }
}

この特性はほとんど一般的すぎるようです。 上記のすべての例では、 try_intoと呼ぶよりも、実際に何をしているのかを明示的に言う方がはるかに良いでしょう。

TryInto<...>またはTryFrom<...>のパラメーターがあると、疑わしい形式のように思えます。

また同意します。 関数に値を渡す前に、変換を実行してエラーを処理しないのはなぜですか？

std :: err :: Errorは＃！[no_std]ビルドに存在しません。 また、多くの場合、エラータイプのstd :: err :: Errorを実装しても、使用可能な場合でもメリットはありません。 したがって、私はそのような限界を持たないことを望みます。

std::error::Errorに制限されることの利点の1つは、別のエラーのcause()の戻り値になる可能性があることです。 core::error::Errorがない理由はよくわかりませんが、調べていません。

また、私はいつもErrorと入力したので、Errorではなく関連するエラータイプにErrという名前を付けるとエラーが発生しやすくなることがわかりました。 この間違いは、RFC自体のドラフト中にも行われたことに気づきました：rust-lang / rfcs＃1542（コメント）。 また、Resultを使用するコードは、Resultコンストラクターであるため、Errという名前をすでに広範囲に使用しています。

安定しているFromStrも、関連付けられた型にErrを使用します。 最高の名前であるかどうかにかかわらず、標準ライブラリ全体で一貫性を保つことが重要だと思います。

TryFromとTryIntoが一般的すぎるかどうかにかかわらず、標準ライブラリで、少なくとも整数型間でのフォールブル変換を本当に見たいと思います。 私はこれのためのクレートを持っていますが、ユースケースはそれを標準にするのに十分に進んでいると思います。 Rustがアルファ版またはベータ版だった頃、この目的でFromPrimitiveとToPrimitiveを使用したことを覚えていますが、これらの特性にはさらに大きな問題がありました。

Errorは、コヒーレンスの問題のため、 coreに移動できません。

また、コヒーレンスの問題により、 Box<Error>はErrorを実装していません。これは、 Errタイプをバインドしないもう1つの理由です。

とにかく、特性定義でそれをバインドする必要は実際にはありません-後でいつでも自分でバインドすることができます：

where T: TryInto<Foo>, T::Err: Error

私は通常これらのスレッドについてコメントしませんが、私はしばらくこれを待っていました、そして上記のいくつかで表現されているように、私はホールドアップが何であるかわかりません。 私はいつも失敗する可能性のあるfrom特性が欲しいです。 try_fromと呼ばれるコードがいたるところにあります...この特性は、そのアイデアを_完全に_カプセル化します。 安定したサビに使用させてください。

私は他にもたくさんのことを書きましたが、残念ながらそれを削除しました。特性の一貫性により、この特性が私にとって可能な限り有用であることが妨げられています。 たとえば、基本的に、これらの型の非常に一般的なパーサーのプリミティブ型に対して、これとまったく同じ特性の特殊なバージョンを再実装しました。 心配しないでください、私はこれについて改めて怒鳴ります。

そうは言っても、 str :: parseは、境界としてFromStrトレイトを特殊化するため、これから大きなメリットが得られると思います。これは、正確に（ TryFrom<str> ）手で特殊化されています。

ですから、私が間違っている場合は訂正してください。ただし、これを安定させてstr::parseに使用すると、次のようになります。

1. ボイラープレートの再実装を削除して、あまり馴染みのない特殊な特性を削除します
2. 署名にTryFrom<str>を追加します。これは、変換モジュールに適切に含まれており、それが何をするのかがより簡単にわかります。
3. アップストリームクライアントがデータ型にTryFrom<str>を実装し、 str.parse::<YourSweetDataType>()を無料で入手できるようにします。また、他のtry_fromを実装したいと思うため、論理コードの編成が向上します。

最後に、抽象化はさておき、コードの再利用、何とか何とか、このような特性の控えめな利点の1つは、初心者とベテランの両方に提供するセマンティック購入です。 基本的に、それらは、馴染みのある標準化された動作を備えた均一なランドスケープを提供します（または提供し始めます。 Default 、 From 、 Cloneは、この良い例です。 これらは、ユーザーが特定の操作を実行するときに到達できる、記憶に残る機能ランドスケープを提供し、その動作とセマンティクスはすでに十分に理解しています（一度学習して、どこにでも適用できます）。 例えば：

1. デフォルトバージョンが必要です。 ああ、 SomeType::default()で連絡させてください
2. これを変換したいのですが、 SomeType::from(other)が実装されているのでしょうか（ドキュメントにアクセスしなくても、入力するだけでコンパイルできるかどうかを確認できます）
3. これを複製したい、 clone()
4. 私はこれからこれを取得しようとします、そしてエラーはさびの不可欠な部分であるため、それは署名で失敗する可能性があります、それで私にtry_fromをさせてください-ああ待ってください：P

これらのメソッドはすべて一般的になり、Rustユーザーツールキットの一部になります。これにより、ドキュメントとセマンティック動作がすでに内部化されている使い慣れた概念（およびこれはTraitの別名です！）に到達できるため、論理的な負担が軽減されます。

もちろん、それらは常に一致するとは限りません。その場合、データ構造を専門化しますが、このような特性は、ドキュメントを読んだり、 from_some_thingなど。ドキュメントを読まなくても、stdトレイトを使用することで、ユーザーは論理的で堅牢かつ効率的な方法でAPIとデータ構造をナビゲートできます。

ある意味では、それは私たちの間で紳士の合意を形式化するものであり、私たちが特定のなじみのある操作を実行することをより簡単でよりなじみのあるものにします。

そして、それについて私が言わなければならないのはそれだけです;）

これは、間違いのない整数変換のエラータイプとして!を使用する可能性の調査で以前はブロックされていました。 この機能は現在実装されているため、これは最も単純な場合でも失敗します： https：//is.gd/Ws3K7V。

メソッド名を変更することをまだ考えていますか、それともこの機能をFCPに組み込む必要がありますか？

@sfackler 29行目のリターンタイプをResult<u32, ()>からResult<u32, !>に変更すると、その遊び場リンクが機能します： https ：//is.gd/A9pWbU let Ok(x) = val;を認識できません

@Ixrecは、これらの特性の主な動機は、C整数typedefとの間の変換でした。 機能があれば

fn foo(x: i64) -> Result<c_long, TryFromIntError> {
    x.try_into()
}

これはi686ターゲットではコンパイルされますが、x86_64ターゲットではコンパイルされません。

同様に、 IntoConnectParamsタイプを置き換えたいとしましょう： https：//docs.rs/postgres/0.13.4/postgres/params/trait.IntoConnectParams.html。 毛布impl<T> TryFrom<T> for T { type Error = ! }がある場合、どうすればそれを行うことができますか？ ConnectParamsの再帰的な実装が必要ですが、 !とは異なる具体的なエラータイプがあります。

valがErrタイプの場合、 let Ok(x) = val;が反駁できないパターンであることを認識できません。

そのためのPRが開いていることに注意してください。

機能があれば...

これはうまくいくはずです

fn foo(x: i64) -> Result<c_long, TryFromIntError> {
    let val = x.try_into()?;
    Ok(val)
}

迷惑な+1コメントになるリスクがありますが、マクロ1.1がRust 1.15に到着した後、try_fromがRumaを毎晩Rustに維持する最後の機能になることを述べておきます。 安定したtry_fromが大いに期待されています！

より実質的なメモについて...

これは私がこの機能について最も奇妙だと思うことです。 私が作成するほとんどの関数は結果を返しますが、この特性を試してみる場合を除いて、try_プレフィックスを使用してこれらの関数に名前を付けたことはありません。

これは良い観察ですが、try_プレフィックスの理由は、戻りタイプをResultとして識別する必要があるためではなく、間違いのない同等のものと区別する必要があるためだと思います。

また、私はいつもErrorと入力したので、Errorではなく関連するエラータイプにErrという名前を付けるとエラーが発生しやすくなることがわかりました。 この間違いは、RFC自体のドラフト中にも行われたことに気づきました：rust-lang / rfcs＃1542（コメント）。 また、Resultを使用するコードは、Resultコンストラクターであるため、Errという名前をすでに広範囲に使用しています。

私はこれに同意します。 私がライブラリで遭遇した他のほとんどのエラータイプは「エラー」という名前で、これまでのところ「エラー」はResult::Errを意味するだけでした。 「Err」は（しゃれを意図していない）人々が絶えず名前を間違える結果になるので、それを安定させるようです。

@canndrewもちろん作業を行うことは可能ですが、この機能の動機の全体的なポイントは、これらの種類のプラットフォームの違いを簡単に正しく処理できるようにすることです。「x86でコンパイルするがARMではコンパイルしない」というスペース全体を避けたいのです。 。

$＃ FromStr ＃$との一貫性を保つためにErrを選択したと思いますが、安定する前にErrorに切り替えていただければ幸いです。

Rumaを毎晩Rustに保つ最後の機能

同様に、代替の遊び場のバックエンドは、 TryFromにアクセスするために毎晩必要です。 毎晩のserdeのものは私の好みには不安定すぎたので、ビルドスクリプトのセットアップに移りました。 1.15で、 #[derive]に戻ります。 この機能が安定するのを心待ちにしています！

@sfackler申し訳ありませんがフォローしていませんでした。 整数変換の場合、本当に必要なのは、プラットフォームに応じてc_ulongをu32またはu64にtypedefするのではなく、何らかの形で新しいタイプにすることです。 そうすれば、 TryFrom<c_ulong> implがTryFrom<u{32,64}> implに干渉することはありません。
結局のところ、異なるプラットフォームで型を異なる方法で定義すると、常に「一方のプラットフォームをコンパイルするが、もう一方のプラットフォームはコンパイルしない」という問題が発生します。 疑わしい慣行のように見えることをサポートできるようにするために、そうでなければ完全に論理的なTryFrom<T> for U where U: From<T> implを犠牲にしなければならないのは残念です。

整数のニュータイプRFCが書き込まれ、マージされ、安定化されるまで、このRFCをブロックすることを真剣に提案しているわけではありません。 しかし、将来のためにそれを心に留めておく必要があります。

同様に、IntoConnectParamsタイプを置き換えたいとしましょう。

ここでの問題は何ですか？ TryFrom<ConnectParams>に1つのエラータイプを使用し、 TryFrom<&'a str>に別のエラータイプを使用しないのはなぜですか？

私は、文字通り世界中のすべてのFFIコードを破ることを主張しません。 Wrappingのような同様の整数のニュータイプラッパーを取得しようとして失敗したため、人間工学的に多大なコストがかかります。

標準ライブラリにimpl<T> From<!> for Tはありますか？ ドキュメントには表示されませんが、それはrustdocのバグである可能性があります。 そこにない場合は、 TryFrom<ConnectParams> implの! Errorを実際に必要なものに変換する方法はありません。

ラッピングのような同様の整数のニュータイプラッパーを取得しようとして失敗したため、人間工学的に多大なコストがかかります。

自分の整数型を定義できるようなものを考えていました。 ラ。 C ++：

trait IntLiteral: Integer {
    const SUFFIX: &'static str;
    const fn from_bytes(is_negative: bool, bytes: &[u8]) -> Option<Self>; // or whatever
}

impl IntLiteral for c_ulong {
    const SUFFIX: &'static str = "c_ulong";
    ...
}

extern fn foo(x: c_ulong);

foo(123c_ulong); // use a c_ulong literal
foo(123); // infer the type of the integer

それはほとんどの人間工学的問題を解決しますか？ 私は実際には、C ++のユーザー定義リテラル、または混乱を招く方法で言語を変更する力を人々に与える一般的な機能は好きではありませんが、2つの悪のうちの小さい方になる可能性があると思います。

標準ライブラリにimpl<T> From<!> for Tはありますか？

From<T> for T implと競合するため現在はありません。 私の理解では、implスペシャライゼーションは最終的にこれを処理できるはずです。

それは、2、3年後には元に戻すべきもののように聞こえます。

スペシャライゼーションと!の安定化のタイムラインは何ですか？

専門化についてはわかりません。 !自体の場合、パッチをマージできるかどうかはほとんどの場合問題です。

@canndrew私はそれがすべてに実装されるべきではないことに間違いなく同意します。 ドキュメントには、_変換を介してSelfを構築しようとする_と書かれていますが、変換としてカウントされるものは何ですか？ 同じことをある表現から別の表現に変更したり、ラッパーを追加または削除したりするのはどうですか？ これには、 Vec<u8> -> StringとMutex<T> -> MutexGuard<T>のほか、 u32 -> charと&str -> i64などが含まれます。 SocketAddr -> TcpStreamとprocess::Child -> process::Outputを除外します。

impl From<T> for UはおそらくTryFrom<T, Err=!> for Uを意味するはずだと思います。 それがないと、 TryFrom<T>をとる関数もFrom<T>をとることができません。 （具体的なtry_from() | try_into()を使用すると、間違いのない変換はおそらくアンチパターンになります。それは可能ですが…ばかげているので、しないでください。 。）

私はimplFromのように感じますUはおそらくTryFromを意味するはずですUのための。

同意しました。

あなたはそれをすることができるでしょう、しかし…それはばかげているでしょう、それでただそうしないでください。

潜在的なクリップのようなリントのように聞こえます。

@BlacklightShining出力タイプが与えられると、「変換」が明らかなタイプに実装する必要があると思います。 複数の変換（utf8 / 16/32？シリアル化とキャスト？など）が可能になり次第、回避する必要があります。

私見では：

今のところ、 FromStrを実装するすべてのものにTryFrom<&str>の包括的な実装を簡単に提供できます。

impl<'a, T: FromStr> TryFrom<&'a str> for T {
    type Err = <T as FromStr>::Err;
    fn try_from(s: &'a s) -> Result<T, Self::Err> {
        T::from_str(s)
    }
}

try_fromが安定する前に、このようなものが追加されるか、少なくともドキュメントでそれを参照するようにしたいと思います。 そうしないと、 TryFrom<&'a str>とFromStrの実装が異なると混乱する可能性があります。

私はそれが良い包含であることに同意します、しかしそれは提案されたTry-> TryFrom implと矛盾するかもしれませんか？

@sfacklerの可能性があります。 TryFrom 、 TryInto 、およびFromStrがすべてドキュメントで相互に参照されていれば、まったく問題ありませんが、私の主な関心事は、 str::parseかどうかを示す既存の標準がないことです。 str::try_intoは同じ値を返します。

誰かが彼らが異なる可能性があると思うかもしれないケースを確かに見ることができますが、私は人々が同じ振る舞いをするためにそれらを実装するべきであるというドキュメントのソフトリクエストで大丈夫でしょう。

たとえば、誰かがWebサイトのPassword構造体を作成したとします。 "password".parse()がパスワードの有効性をチェックしてからハッシュに変換すると想定する場合がありますが、 Password::try_from("1234abcd")は、 "1234abcd"がすでにデータベースに格納されているハッシュであると想定して試行します。比較可能なハッシュに直接解析します。

parseの表現が、あるレベルの解析が行われることを意味するのに対し、 try_fromは単なる型変換であることを考えると、これは理にかなっています。 ただし、実際には、これらの機能の両方が同じことを実行することを意図していることを明確にしたいと思うかもしれません。

言語チームは匿名パラメーターを非推奨にするためにRFCを閉じることを提案しましたが、理想的には匿名パラメーターを使用する新しいコードの作成を停止することに全員が同意しているようです。 それを念頭に置いて、 try_from / try_intoの署名を更新して、パラメーターに名前を付けることができますか？ それとも、 from / intoとの対称性を維持することがより重要でしょうか？

また、まだ残っている主要な未回答の質問の要約を書くことは有用でしょうか？ 次のリリースサイクルのためにこれを安定させることを決定できることを本当に望んでいます。 私が言ったように、それは私がよく使う唯一の残りの夜の機能です。 ：}

@jimmycuadra確かにそうです！ いくつかのパラメータ名を追加してPRを送信したいですか？

現状については、答えがないのは、あるべきかどうかだけだと思います。

impl<T, U> TryFrom<U> for T
    where T: From<U>
{
    type Error = !;

    fn try_from(u: U) -> Result<T, !> {
        Ok(T::from(u))
    }
}

これにより、ある程度の対称性が追加されますが、変換するものに対して単一のエラータイプがなくなるため、多くの場合、処理が少し面倒になります。

タイプエラー= ！;

!に関するすべての未決定のものについて決定された結果を考慮に入れた別のRFCでそれを行うことをお勧めします。

@sfackler FromStrについても言及したことを考慮に入れることが重要だと思います。 FromStrの実装者に対して同様の実装を行う必要がありますか、それとも区別できるようにする必要がありますか、それとも同じである必要はないが同じである必要があることを文書化する必要がありますか？

TryFrom<str>とFromStrは機能的に同一である必要があり、ドキュメントでは、2つの実装が同一であることが意図されていることを明確にする必要があると思います。 一方を実装すると、少なくともstr::parseの使用を許可するという点で、もう一方も提供されるはずです。 Rustが最初からTryFromを持っていたとしたら、 FromStrは必要なかったでしょう。 そのため、新しいコードの推奨フォームとしてTryFrom<str>も文書化します。

その場合、 @ jimmycuadraは、 parse TryFrom使用してから、 FromStr -> TryFromのブランケットimplを配置する必要があります。

str::parseをTryFromの観点から実装するように変更する場合、具体的な型のFromStrの他の実装も同様に変更する必要があります（つまり、このリストのすべての実装者） ：https：//doc.rust-lang.org/stable/std/str/trait.FromStr.html）？ FromStrのドキュメントを更新して、代わりにTryFromを使用することを提案する必要がありますか？ FromStrの現在の具体的な実装では、ドキュメントをTryFromバージョンに移動する必要がありますか？

下位互換性のために、 FromStrを変更することはできないと思いますよね？

$＃$ TryFrom<&str> FromStrを削除することは、Rust2.0で間違いなく覚えておくべきことです。

はい、この機能が安定したら、問題を報告し、2.0-breakage-wishlistのタグを付けます。

また、考慮すべきことの1つは、$ TryFrom<String> Stringにparse_intoメソッドを追加することです。 タイプが内部的にStringを格納しているが、それでも検証が必要な場合は、両方にTryFromを実装することがよくあります。

implを残す場合TryFrom for T where T：From 将来のRFCのために、この機能は今すぐ安定する準備ができていますか？ 私は本当に別のリリースサイクルを見逃したくないので、Rustチームの何人かの人々が議論して決定を下すための帯域幅を持っていることを望んでいます。

問題は、機能が安定した後、その機能を安定させるのが難しく、人々が両方にimplを提供したことだと思います。

実装が合理的である場合、すでにT : From<U>を持っていると、$ U : TryFrom<T>が変更の「明らかなAPIホール」カテゴリに入れられると思います。

これは、少なくともT : TryFrom<T>とError = !が必要であることを意味しますが、間違いのないFromのバージョンは明らかにそれよりも優れています。

IMOは、 FromがTryFromの実装を提供するか、 TryFromがFromの実装を提供するかを明確に区別していません。

なぜなら、一方ではT::from(val)をちょうどT::try_from(val).unwrap()と見なすことができ、他方ではT::try_from(val)をちょうどOk(T::from(val))と見なすことができるからです。 どちらが良いですか？ わからない。

T::from(val)はT::try_from(val).unwrap()と見なすことができます

私はそれに同意しません。 Fromの実装がパニックになることはありません。 逆の方法だけが理にかなっています。

@clarcharr Fromは慌てる必要がないため、オプションは$ TryFrom<Error=!>またはその逆の観点からFromです。 ただし、「 Fromを実装する必要があります」ではなく、「 TryFromをtype Error = !で実装する必要があります」という通常のアドバイスは必要ありません。

これを安定させるための動きを得る方法はありますか？ 1.18がベータ版に入る前に時間が不足しています。 @sfackler？

@rfcbotfcpマージ

チームメンバーの@sfacklerは、これをマージすることを提案しました。 次のステップは、タグ付けされた残りのチームによるレビューです。

• [x] @BurntSushi
• [x] @Kimundi
• [x] @alexcrichton
• [x] @aturon
• [x] @brson
• [x] @sfackler

現在リストされている懸念はありません。

これらのレビューアが合意に達すると、これは最終コメント期間に入ります。 このプロセスのどの時点でも提起されていない大きな問題を見つけた場合は、声を上げてください。

タグ付けされたチームメンバーが私に与えることができるコマンドについては、このドキュメントを参照してください。

@sfackler ：チェックインするだけで、 !と包括的実装に関するさまざまな懸念に対応できますか？ これについてはlibsミーティングで話し合ったと思いますが、ここで要約を入手しておくと役に立ちます。

@aturonそれについての最後の議論は、 impl From<T> for Uがimpl TryFrom<T> for Uを提供するべきかどうか疑問に思っていた@sfacklerでした。ここでTryFrom::Error = ! 。

@briansmithは、neverタイプに関する未解決の質問が解決されたら、それを別のRFCにするという決定を提案しました。

これを安定させることの主な問題は、下位互換性を壊さずにそのような変更を行うことができないということではありませんか？ それとも、その変更を進めないための解決策ですか？

私は、現在のimplのセットは受け入れられないと思います。 私はこれらの立場のどちらかを理解することができました：

1. TryFromは、フォールブルコンバージョンのみを対象としているため、 u8 -> u128やusize -> usizeなどはありません。
2. TryFromは_all_変換を対象としており、その一部は間違いなく、無人のTryFrom::Errorタイプです。

しかし、現在、コンパイラがi32 -> i32変換のチェックコードを挿入するという奇妙なハイブリッド状態にありますが、 String -> String変換を行うことはできません。

エラータイプとしての!に対する反対意見は何ですか？ 簡単なスキムで気付いたのは、「変換したいもののエラータイプが1つではなくなったため、多くの場合、処理が少し面倒になる」ということだけでしたが、私は同意しません。それで、あなたはあなたが何があっても一般的な文脈でカスタムエラータイプで何かカスタムを渡されたと仮定しなければならないので。

これを安定させることの主な問題は、下位互換性を壊さずにそのような変更を行うことができないということではありませんか？ それとも、その変更を進めないための解決策ですか？

Fromが実装されているときに、 TryFromの一般的な実装を追加するのは熱心すぎると思います。 Fromの実装がある場合、エラーを生成できないTryFromの実装があることは意味的には正しいですが、この提供された実装が実際に役立つとは思えません。十分に一般的なニーズであるため、デフォルトで提供する必要があります。 誰かが何らかの理由でそのタイプの動作を本当に必要としている場合、それはたった1つの簡単な実装です。

間違いのない変換にfrom try_fromを使用したことがある場合の例があれば、私は確かに考えを変えることができます。

反対意見は何ですか！ エラータイプとして？

!は、安定化から数か月先です。 近い将来にTryFromを安定させるか、 impl<T, U> TryFrom<U> for T where T: From<U>を使用するかのいずれかを選択してください。

ここで特性エイリアス（rust-lang / rfcs＃1733）を使用することを検討しましたか？ それが着地したら、 From<T>をTryFrom<T, Error=!>にエイリアスして、2つの特性を同じにすることができます。

@lfairy残念ながら、 Fromのユーザーimplを壊してしまいます。

@glaebhoerlええ、その通りです😥そのRFCの動機付けのセクションでは、 implのエイリアシングについて言及していますが、実際の提案ではそれらは許可されていません。

（そうでなかったとしても、メソッドの名前などは異なります）

それは2.0のウィッシュリストの下に入る可能性がありますが、それにもかかわらず、何も壊さずに起こることはありません。

まず、IRCでこれについて素晴らしい会話をしてくれた@sfacklerに感謝します。 物事を少し頭の中に置いた後、ここで私は終わりました。

近い将来にTryFromを安定させるか、 impl<T, U> TryFrom<U> for T where T: From<U>を使用するかのいずれかを選択してください。

ここでの中心的な問題は、間違いのない変換が特性に属するかどうかだと思います。 RFCでの間違いのない変換のようなものや、一般的な使用（一見役に立たないT:From<T>がある方法に類似）のために、それらは機能すると思います。 それを考えると、私が最も望んでいるのは、すべての型実装者がimpl TryFrom<MyType> for MyTypeになると予想される世界を避け、すべてのFrom implもTryFrom implになるはずです。 （または、バグを提供しないために後でバグを提出してください。）

では、 !を安定させることなく、ブランケットimplを使用できますか？ ライブラリにはすでに!のようなタイプ（ std::string::ParseErrorなど）があるので、方法があると思います。 （ "この列挙型は少し厄介です。実際には存在しません。 "）

これがどのように機能するかのスケッチ：

• 新しいタイプのcore::convert::Infallibleは、 std::string::ParseErrorとまったく同じように実装されています。 （たぶん、後者を前者のタイプエイリアスに変更することさえできます。）
• impl<T> From<Infallible> for Tは、 ?で任意のエラータイプと互換性があるようにします（後でc_fooのものを参照してください）
• ブランケットimplのErrorタイプとしてInfallibleを使用します
• 後で、never型を安定させる一環としてtype Infallible = !;を検討してください

それを具体化するのに役立つなら、私はそれをするPRをすることを志願します。

c_fooについて：上記は引き続き次のようなコードを許可します：

fn foo(x: c_int) -> Result<i32, TryFromIntError> { Ok(x.try_into()?) }

ただし、エラータイプが異なるため、このようなコードは移植性のある「フットガン」になります。

fn foo(x: c_int) -> Result<i32, TryFromIntError> { x.try_into() }

個人的には、 c_intがタイプエイリアスである限り、「フルオート」フットガンがあるので、その違いについては心配していません。

fn foo(x: c_int) -> i32 { x }

そして、一般的に、トレイトの関連するタイプが異なるimplに対して同じであることを期待するコードは、コードの臭いのように感じます。 TryFromを「 Fromを一般化する」と読みました。 目標が「整数サブセット間のより良い変換」である場合（これも便利だと感じます）、「常に同じエラータイプ」は論理的ですが、代わりにstd::numでターゲットにされたもの、おそらくnum::cast::NumCastのようなものを期待しますboost::numeric_cast ）。

（余談ですが、FCPマージで#[repr(transparent)]を使用すると、 c_foo型がニュータイプになる可能性があり、その時点でこれらの変換の一貫性が高まります。From＆TryFrom implsは、C "char <= short <をコード化できます。 = int <= long "ルール、およびそれらに標準で必要な最小サイズ（ c_int:From<i16>やc_long:TryFrom<i64>など）。上記の変換は、すべてでi32:TryFrom<c_int>になります。常に同じErrorタイプのプラットフォームであり、問​​題は解決します。）

「この列挙型は少し厄介です。実際には存在しません。」について

エラータイプが単なる単位ではない理由はありますか？ 会話でエラーが発生しないのに、なぜ独自のParseError構造体を気にする必要があるのでしょうか。

@sunjay ()は、「これは発生する可能性がありますが、発生したときに通知する興味深いことは何もありません」の型システム表現です。 無人型（ !やstd::string::ParseErrorなど）は逆で、型システムが「この状況は決して起こり得ないので、対処する必要はありません」と言います。

@jimmycuadra

間違いのない変換のためにfromの代わりにtry_fromを使用したことがある場合の例があれば、私は確かに私の考えを変えることができます。

@scottmcm

ここでの中心的な問題は、間違いのない変換が特性に属するかどうかだと思います。

私のユースケースは次のとおりです。値がbool、numeric、またはstringである構成ファイル形式と、キーが列挙型バリアントまたは文字列であるリテラル構成値を書き込むためのマクロがあります。 例えば：

let cfg = config![
    BoolOpt::SomeCfgKey => true,
    "SomeOtherCfgKey" => 77,
];

簡単に言うと、マクロは最終的に($k, $v).into()呼び出しのリストに拡張されます。 文字列キーの変換をチェックして、有効な構成オプションに名前が付けられていることを確認したいと思います。つまり、 TryFrom<(String, ???)>を実装し、マクロを($k, $v).try_into()を使用するように変更します。 マクロがすべての変換に使用する単一のメソッド名がない場合、これをすべて行うのは難しくなります。

：bell：上記のレビューによると、これは現在、最終コメント期間に入っています。 ：ベル：

私は実際に次のアイデアが本当に好きです：

impl<U: TryFrom<T, Error=!>> From<T> for U {
    fn from(val: T) -> U {
        val.unwrap()
    }
}

TryFrom<Error=!>が欲しい人は誰でもそれを実装できますが、必要に応じてFromを実装することもできます。 おそらく、最終的にFromを廃止することはできますが、そうする必要はありません。

空の列挙型を使用する@scottmcmの計画は、私には素晴らしいと思います。

@ Ericson2314あなたが書いた：

エラータイプにプレーンなFromを使用する場合は違います（例： try! ）！ impl<T> From<!> for Tは、その目的のために存在することができ、存在する必要があります。

これは実際にはどのように機能しますか？ 次のような関数を作成しようとしているとします。

fn myfn<P: TryInto<MyType>>(p: P) -> Result<(), MyError>

もちろんこれが機能しないことを除いて、 TryInto Error=を指定する必要があります。 しかし、私はそこにどのタイプを書くべきですか？ MyErrorは当たり前のようですが、 MyTypeをブランケットTryFrom implで使用することはできません。

次のことを提案していますか？

fn myfn<E: Into<MyError>, P: TryInto<MyType, Error=E>>(p: P) -> Result<(), MyError>

それはかなり冗長に思えます。

同じタイプでエラータイプが異なる複数の「間違いのない」変換が必要な場合、これがどのように機能するかについてのより一般的な質問があります。

たぶん、 TryFromの定義を次のように変更する必要があります。

pub trait TryFrom<T, E>: Sized {
    type Error: Into<E>;

    fn try_from(t: T) -> Result<Self, E>;
}

次のように明示的な名前を付けることなく、エラーをMyErrorに変換できるように制限できます。

fn myfn<P: TryInto<MyType>>(p: P) -> Result<(), MyError> where MyError: From<P::Error>

それはまだ少し冗長ですが、実際には関数をうまく呼び出すための制約を述べています（遊び場）

編集： IntoのFromの包括的な実装がないため、 P::Error: Into<MyError>のようなバリアントを試してみると、実際には? $では機能しません。 あなたが示したようにTryFromを変更すると、同じ問題が発生することが予想されます。

これで最終コメント期間が終了しました。

@jethrogbええ、あなたは1年前から私を引用したので、少し考えなければなりませんでした。 @ Nemo157は絶対に正しいです、そしてそれは合理的なようです。

!の特定のケースでは、包括的implが必要ですが、それが別のものと重複していることを思い出します。 両方の実装が実装に同意しているので、これは厄介な重複です---未定義の動作/デッドコード。

別の問題からのこれに関するコメント： https ：//github.com/rust-lang/rust/pull/41904#issuecomment -300908910

libsチームの誰かがscottmcmのアイデアについて考えていますか？ それは私にとって素晴らしいアプローチのように思えます、そして私は別のリリースサイクルを逃した後もこの機能を前進させ続けたいと思います。

libsチームは、数週間前にこれについて再び話しました（これを書くのが遅れてすみません）！ この機能に関する問題の原因は、主にFFIのケースがこれらの特性の他のユースケースに実際には適合しないことであるという結論に達しました。これは、さまざまなエイリアスを介して具体的なタイプで呼び出すという点で独特です。ターゲットに基づいています。

したがって、基本的なアクションプランは、 impl<T, U> TryFrom<T> for U where U: From<T>を追加し、間違いのない整数変換の明示的なimplを削除することです。 FFIのユースケースを処理するために、別のAPIを作成します。

!でのブロックを回避するために型エイリアスを使用することは、興味深いものです。 私の唯一の懸念は、 !が通常の無人タイプよりも「特別」であり、エイリアスを無人列挙型から!に交換したときに破損する可能性があるかどうかです。

整数型の「個別のAPI」のPRを開きました： https ：//github.com/rust-lang/rust/pull/42456

変換が多いにもかかわらず、 TryIntoまたはTryFromでパラメーター化されたジェネリックコードを作成する必要がなかったため、定義する型でのすべての使用には後者の形式で十分です。 TryInto<...>またはTryFrom<...>のパラメーターがあると、疑わしい形式のように思えます。

派生トレイトの一部として安定したらTryFromを使用するつもりですが、 deriveマクロの一部として一部のタイプでアドホック組み込みメソッドを呼び出すのは本当に奇妙です。

これは削除しないでください。

TryIntoまたはTryFromによってパラメーター化されたジェネリックコードを作成する必要はありませんでした

そうだとしても、それでTryIntoとTryFromの有用性が大幅に低下するとは思いません。 私はIntoとFromを、一般的でないコンテキストの至る所で使用しています。 implの標準ライブラリ特性を追加すると、アドホックな固有の変換方法の束よりもはるかに「通常」で「期待」されているように感じます。

TryIntoまたはTryFromによってパラメーター化されたジェネリックコードを作成する必要はありませんでした

私のプロジェクトの1つから：

pub fn put_str_lossy<C, S> (&self, s: S)
    where C: TryInto<ascii::Char>,
          S: IntoIterator<Item = C>
{
    for c in s.into_iter() {
        self.put_char(match c.try_into() {
            Ok(c) => c,
            Err(_) => ascii::QUESTION_MARK,
        });
    }
}

これらの特性の実装は特定の法律に従うことが期待されますか？ たとえば、AをBに、BをAに変換できる場合、変換が成功したときに反転可能である必要がありますか？：

#![feature(try_from)]

use std::convert::{TryFrom, TryInto};

fn invertible<'a, A, B, E>(a: &'a A) -> Result<(), E>
    where A: 'a + TryFrom<&'a B>,
          A: PartialEq,
          B: 'a + TryFrom<&'a A>,
          E: From<<A as TryFrom<&'a B>>::Error>,
          E: From<<B as TryFrom<&'a A>>::Error>,
{
    let b = B::try_from(a)?;
    let a2 = A::try_from(&b)?;
    assert!(a == &a2);
    Ok(())
}

編集：s / reflexive / invertible /

@briansmith Fromがどのように機能するかを考えると、この方法では反転できないと思います。

use std::collections::BinaryHeap;

fn main() {
    let a = vec![1, 2];
    let b = BinaryHeap::from(a.clone());
    let c = Vec::from(b);
    assert_ne!(a, c);
}

だから私はこの特性の現在の実装について疑問に思っています。 ＃43127（＃43064も参照）で出てきたように、それが純粋に実装がi / u128を使用しているためかどうかはわかりませんが、TryIntoの呼び出しはインライン化されていないようです。 これはあまり最適ではなく、ゼロコストの抽象化の精神ではありません。 たとえば、 <u32>::try_into<u64>()を使用すると、最終的なアセンブリで単純な符号拡張に最適化する必要があります（プラットフォームが64ビットの場合）が、代わりに関数呼び出しが発生します。

特性の実装がすべての整数型で同じでなければならないという要件はありますか？

＃42456によると、整数型に直接impl TryFromがない可能性がありますが、その「NumCast」トレイト（＃43127に切り替える必要がある）がどのように見えるかはまだ作成中です。

最終的に別の特性に移行するかどうかに関係なく、これらの変換は現在libcoreに実装されており、libcoreで使用できます。 すべての整数変換にu128 / i128を使用するのは、ソースコードを単純化するためだと思います。 代わりに、ソースタイプが宛先よりも広いか狭いかに応じて、異なるコードを使用する必要があります。 （おそらく、 #[cfg(target_pointer_width = "64")]と#[cfg(target_pointer_width = "32")]と#[cfg(target_pointer_width = "16")]に基づくさまざまなマクロ呼び出しを使用します。）

注意：これをブロック解除するのにそれほど多くは必要ありません！ あなたがそれを望んでいるなら、 @ sfacklerの要約を見て、私または他のlibsチームメンバーにガイダンスを求めて遠慮なくpingしてください。

強打タイプが不安定になるための回避策として@scottmcmのアイデアを使用できるというlibsチームからの賛同があることに気づいていませんでした。 回避策を使用して、PRに取り組み、 @ sfacklerが言及した変更を加えることができます。

素晴らしい、ありがとう@jimmycuadra！

この議論のほとんどは、整数型にTryFromを実装することを中心に展開しているようです。 私の意見では、 TryFromが安定するかどうかは、これらのタイプのせいだけではありません。

&[T; N]のTryFrom<&[T]>など、これらの特性から恩恵を受ける他のきちんとした変換があります。 私は最近、これを正確に実装するためのPRを提出しました： https：//github.com/rust-lang/rust/pull/44764。

このような変換は、 TryFromを安定させるために私にとって十分に重要です。

＃44174がマージされたことで、これはブロック解除されたと思います。

そのPRは、$ TryFrom<&str>を実装するすべての型のFromStrの自動実装を削除しました。これは、型システムが現在、特殊化されていても、それをサポートできないためです。 この機能が安定すると、 FromStrとparseは廃止され、 TryFrom<&str>とtry_intoが優先されます。 2つの間の暫定的な互換性が失われるのは残念です。一時的なアイデアがある場合は、声を上げてください。

これ以上変更を加える必要がなく、libsチームの誰かが安定化のためにこれを青信号にした場合、安定化PRとPRを実行して、 FromStr / parseを非推奨にすることができます。

FromStr / parseを非推奨にするPR。

代替品がStableで利用可能になるまで（またはhttps://github.com/rust-lang/rust/issues/30785が実装されるまで）、非推奨の警告をNightlyに追加しないでください。これにより、いつでも3つのリリースチャネルすべてで警告なしでクレートビルド。

参照によって電子メール通知が生成されないため、他のPRを見逃しました。 特定のimpl From<Infallible> for TryFromIntErrorがあることに気づきました。 議論したように、それはimpl<T> From<Infallible> for Tであるべきではありませんか？

@jethrogb残念ながら、これはimpl<T> From<T> for Tと競合するため、実行できません（交差点が取得されるまでは？-そして!を使用しても機能しません）。

@scottmcmああもちろん。

交差点の実装は必要ないと思いますか？ それは単なる専門分野ではありませんか？

私は他のコメントを読んでいませんが、 TryFromは今私のために壊れています（以前はうまくいきました）。

rustcバージョン：

rustc 1.22.0-nightly (d6d711dd8 2017-10-10)
binary: rustc
commit-hash: d6d711dd8f7ad5885294b8e1f0009a23dc1f8b1f
commit-date: 2017-10-10
host: x86_64-unknown-linux-gnu
release: 1.22.0-nightly
LLVM version: 4.0

rustが文句を言う関連コードセクションはここにあります： https ：//github.com/fschutt/printpdf/blob/master/src/types/plugins/graphics/two_dimension/image.rs#L29 -L39およびhttps：// github .com / fschutt / printpdf / blob / master / src / types / plugins / graphics / xobject.rs＃L170 -L200-数週間前に正常にコンパイルされたため、ライブラリにはまだ「ビルドパス」バッジがあります。

ただし、最新のナイトリービルドでは、 TryFromが壊れているようです。

error[E0119]: conflicting implementations of trait `std::convert::TryFrom<_>` for type `types::plugins::graphics::two_dimensional::image::Image`:
  --> src/types/plugins/graphics/two_dimensional/image.rs:29:1
   |
29 | / impl<T: ImageDecoder> TryFrom<T> for Image {
30 | |     type Error = image::ImageError;
31 | |     fn try_from(image: T)
32 | |     -> std::result::Result<Self, Self::Error>
...  |
38 | |     }
39 | | }
   | |_^
   |
   = note: conflicting implementation in crate `core`

error[E0119]: conflicting implementations of trait `std::convert::TryFrom<_>` for type `types::plugins::graphics::xobject::ImageXObject`:
   --> src/types/plugins/graphics/xobject.rs:170:1
    |
170 | / impl<T: image::ImageDecoder> TryFrom<T> for ImageXObject {
171 | |     type Error = image::ImageError;
172 | |     fn try_from(mut image: T)
173 | |     -> std::result::Result<Self, Self::Error>
...   |
199 | |     }
200 | | }
    | |_^
    |
    = note: conflicting implementation in crate `core`

error: aborting due to 2 previous errors

error: Could not compile `printpdf`.

したがって、おそらくそれはクレートcoreに重複した実装を持っています。 誰かがこれを調べることができれば、それは素晴らしいことです、ありがとう。

@fschutt競合するimplはおそらくimpl<T, U> TryFrom<T> for U where U: From<T>で、 https：//github.com/rust-lang/rust/pull/44174に追加されています。 T: ImageDecoderとImage: From<T>の両方のようなTが存在する可能性があります。

これが機能ゲートを離れるためにまだ必要なものはありますか？

https://github.com/rust-lang/rust/issues/35121が最初に安定した場合、 https ：//github.com/rust-lang/rust/pull/で導入されたInfallibleタイプを削除できます。 44174そして代わりに!を使用してください。 これが要件と見なされるかどうかはわかりません。

ここでの主なブロッカーはまだ整数型だと思います。 整数型https://github.com/rust-lang/rust/pull/42456#issuecomment-326159595に個別のCastトレイトを使用するか、移植性のlint＃41619を最初に実行します。

だから私はAsRef<str> TryFromを実装する列挙型を持っていましたが、これは数ヶ月前に壊れました。 毎晩発生するバグで、時間の経過とともに解消されると思いましたが、そうではないようです。 これはTryFromでサポートされているパターンではなくなりましたか？

impl<S: AsRef<str>> TryFrom<S> for MyEnum {
    type Error = &'static str;

    fn try_from(string: S) -> Result<Self, Self::Error> {
        // Impl here
    }
}
...

&strとStringの両方から変換するための他のオプションはありますか？

@kybishopはMyEnumがFromStr $を実装しますか？ それがあなたの破損の原因かもしれません。

@nvzqzはそうではありませんが、より一般化されたソリューションであるため、Rust IRC経由でTryFromを使用することをお勧めしました。 TryFromは、数か月前に毎晩重大な変更が発生するまで、最初はうまく機能していました。

編集： FromStrの実装に切り替える必要があるということですか、それとも_did_ impl FromStrの場合、破損を引き起こす可能性があるということですか？

編集2：これが完全な実装です。好奇心旺盛な人のために短くてシンプルです： https ：//gist.github.com/kybishop/2fa9e9d32728167bed5b1bc0b9becd97

@kybishopは、 &str AsRef<str>の実装が必要な特別な理由がありますか？

@sfackler私は、 &strとStringの両方からの変換が可能であるという印象を受けましたが、私はまだRustの初心者なので、 AsRef<str>の正確な方法を誤解している可能性があります。 &strをオフにして、 AsRefが&strで許可されていないことを許可しているかどうかを確認します。

@kybishop https://github.com/rust-lang/rust/issues/33417#issuecomment -335815206と同じで、コンパイラのエラーメッセージにあるように、これはimpl<T, U> std::convert::TryFrom<U> for T where T: std::convert::From<U> implとの実際の競合です。 libcoreに追加されました。

両方を実装するタイプT （おそらくダウンストリームクレート内）が存在する可能性がありますFrom<MyEnum>とAsRef<str>MyEnum: From<T>があります 。 その場合、両方のimplが適用されるため、両方のimplが一緒に存在することは許可されません。

@SimonSapinは理解しました。 では、 &strと&Stringの両方から変換したい人のためのオプションは何ですか？ 両方にTryFromを実装する必要がありますか？

編集：私は余分な仕事を食べて、 String .as_ref()を呼び出すことができると思います。 次に、 strに対して単一のTryFrom implを作成できます。

はい、 MyEnumがFrom<&str>またはFrom<String>を実装していない限り、2つの実装（おそらく、一方が他方に基づいている）が機能するはずです。

@kybishop StringはDeref<str> $を実装するため、型推論により、 TryFrom implに渡すときに&Stringが&strに強制変換できるようにする必要があります。 as_ref電話する必要があるとは限りません。

誰かがこれの簡単な例を探しているなら： https ：//play.rust-lang.org/？gist = bfc3de0696cbee0ed9640a3f60b33f5b＆version = nightly

https://github.com/rust-lang/rust/pull/47630が!を安定させようとしているので、PRがInfallibleを!に置き換える意欲はありますか？ ？

従うべきより良いルートは、エイリアスを作成することです。 表現力を維持し、適応言語機能を使用します。

type Infallible = !;

飛び込んでください。 @ scottmcmを使用しています。

ただし、これにより、この機能（ TryInto / TryFrom ）が別の不安定な機能（ never_type $）に依存するという余分なオーバーヘッドが追加されます。

また、 Infallibleには、型を作成できない理由に関するより多くの情報/セマンティクスを提供するという利点があります。 私は今自分自身に意見を持っています。

!を十分な語彙タイプにして、 Result<_, !>が「間違いのない結果」または「（文字通り）決して誤りのない結果」として直感的に読み取れるようにしたいと思います。 エイリアスを使用すると（別のタイプを気にしないでください！）、少し冗長に思えます。タイプシグネチャを読み取るときに、少なくとも一時的な一時停止が発生することがわかります。「待ってください。これは!とどう違うのですか。 ？」 もちろん、YMMV。

@jdahlstrom私は完全に同意します。 それが「グラウンドトゥルース」で親しみやすいものになるように、Rustブックまたはノミコンでそれを紹介する必要があります。

このAPIのRFCが提出されてから2年になります。

〜 @ briansmith ：安定化PRが進行中です。〜

編集：または多分私はあまりにも疲れています...

!タイプの安定化のPRをリンクしました。

!安定化PRがマージされたばかりなので、$ convert::Infallibleを!に置き換えるためのPRを提出しました：＃49038

https://github.com/rust-lang/rust/pull/49038がマージされます。 これが安定化の最後の阻害要因だったと思います。未解決の問題を見逃した場合はお知らせください。

@rfcbotfcpマージ

https://github.com/rust-lang/rust/issues/33417#issuecomment -302817297で別のFCPがすでに完了しているため、rfcbotが応答していません。

うーん、再検討する必要があるいくつかの実装があります。 impl<T, U> TryFrom<U> for T where T: From<U>ができたので、 type Error = ! TryFromの残りのimplは、 Fromのimplに置き換えるか、削除するか、フォールブルにする必要があります（エラータイプを無人タイプに変更します）。

その場合、私が見つけることができるのはusizeまたはisizeです。 対応するFrom implは、フォールビリティがターゲットポインタのサイズに依存するため、存在しないと思います。 実際、 TryFrom implは、ターゲットごとに異なる方法で生成されます。https ：//github.com/rust-lang/rust/blob/1.24.1/src/libcore/num/mod.rs#L3103-L3179これおそらく携帯性の危険です。

ターゲットごとに生成が異なります

明確にするために：同じimpl target_pointer_widthの異なるメソッド本体は問題ありません（そしておそらく必要です）が、異なるAPI（エラータイプ）はそうではありません。

安定化PR：＃49305。 そこでの議論の後、このPRは、 usizeまたはisizeを含むいくつかのTryFrom implも削除します。これは、それらを実装する2つの異なる方法のどちらかを決定していないためです。 （もちろん、1つしか持てません。）

それらのための専用の追跡問題： https ：//github.com/rust-lang/rust/issues/49415

TryFromは、機能ゲーティングなしでrustc 1.27.0-nightly (ac3c2288f 2018-04-18)で完全に機能しましたが、 rustc 1.27.0-nightly (66363b288 2018-04-28)でコンパイルすると壊れました。

過去10日間、この機能の安定化に後退がありましたか？

@kjetilkjekaこの機能は最近安定していません：＃50121。

（安定化が元に戻されたため、再開します）

@kjetilkjeka TryFromの安定化は、 ! TryFrom<U, Error=!> for T where T: From<U>の安定化とともに、 https：//github.com/rust-lang/rust/pull/50121で元に戻されました。 TryFrom<U, Error=!> for T where T: From<U> impl。 !タイプは、 https：//github.com/rust-lang/rust/issues/49593のために不安定になりました。

説明してくれてありがとう。 これは、コンパイラの型強制に対するいくつかの変更で、この機能が本質的にブロックされることを意味しますか？ どのような変更が必要かを説明する問題が見つかりません。この時点で変更の大きさはわかっていますか？

TryFrom特性自体、および!を含まないimplを先に進めて安定化できず、 !を含むimplの安定化を延期することができなかった根本的な理由はありますか？ !の可能な安定化の後まで？

https://github.com/rust-lang/rust/pull/49305#issuecomment -376293243は、考えられるさまざまな特性の実装を分類しています。

@joshtriplett私が理解している限り、特にimpl<T, U> TryFrom<T> for U where U: From<T> { type Err = !; }は、 TryFromがすでに安定している場合、追加する下位互換性がありません。

@SimonSapin
追加するのに下位互換性がないのはなぜですか？

（そして、私たちは本当にブランケットimplが必要ですか？）

追加するのに下位互換性がないのはなぜですか？

TryFromが安定してから!が安定するまでの間、 TryFromを手動で実装できた可能性があるため、下位互換性はないと思います。 包括的実装が追加された場合、手動実装と競合することになります。

（そして、私たちは本当にブランケットimplが必要ですか？）

TryFromを超えるジェネリックコードを書く場合、ブランケットimplは本当に理にかなっていると思います。 Tに変換される可能性のあるすべてのタイプを参照する場合、ほとんどの場合、確実にTに変換できるすべてのタイプも含める必要があります。 別の方法として、 Fromを実装するすべてのタイプに対してTryFromも実装するように全員に要求し、特殊化を待ってから包括的実装を作成することも考えられます。 Resultをジェネリックにするために$ Errが何であるかという問題がまだあります。 !は、変換の不可謬性を表現し、プログラムで強制するための優れた方法のように思われ、うまくいけば待つ価値があります。

包括的実装を提供し、その間にさまざまな数値変換を安定させるための特殊化が利用可能になるまで、いつでも待つことができます。

Rustで整数変換を慣例的に行う方法について助けを求めている人々の文脈で、これらに対するさまざまな要求を見てきました。そして今日、エラー検出を使用してu64をu32に変換する方法を具体的に考えている人に出くわしました。

私は、専門化によって、事後にブランケットimplを魔法のように追加できるとは確信していません。 現在の提案についての私の理解は、特性は特殊化することを選択する必要があるということです。これは、既存の特性に対して行うには下位互換性がない可能性があります。

これが安定するときはいつでも：_お願い_前奏曲にTryFromとTryIntoを追加してください。

@SergioBenitezしばらくの間、Nightlyでそれを行いましたが、残念ながら、独自のTryFromまたはTryIntoの特性を定義するクレートの重大な変更でした（ stdで使用する場合）

std libsチームがここで学ぶべき教訓は、プレリュードに追加したい特性がある場合は、それが実装されたらすぐに追加し、安定化を待たないことです。

ただし、 TryFromとTryIntoの場合、解決策は2018年版の前奏曲を変えることです。 これは以前に非公式に議論されましたが、ファイルされていなかったので、 https：//github.com/rust-lang/rust/issues/51418を開きました。

同様の問題に対する一般的な解決策が拡張のために実装されました
https://github.com/rust-lang/rust/issues/48919のメソッド、これにより不安定
拡張メソッドは、安定したコードが衝突したときに警告を発行します。

新しい用語を追加して、同様のことができるようです。
プレリュード？

2018年6月7日木曜日、午前11時47分[email protected]は次のように書いています。

@SergioBenitezhttps ：//github.com/SergioBenitez
しばらくの間毎晩、そして残念ながらそれは木枠にとって壊滅的な変化でした
独自のTryFromまたはTryIntoトレイトを定義します（std中に使用するため）
1つは不安定です）、十分に元に戻しました。

std libsチームのためにここで学ぶべき教訓は、
プレリュードに追加したい特性があります。
実装されるとすぐに、安定化を待たないでください。

ただし、TryFromとTryIntoの場合、解決策は異なるものにすることです。
2018年版のプレリュード。 これは以前に非公式に議論されましたが
提出されていなかったので、＃51418を開きました
https://github.com/rust-lang/rust/issues/51418 。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/33417#issuecomment-395525170 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAC2lNbHvgBjWBk48-1UO311-LuUY5lPks5t6XUvgaJpZM4IXpys
。

この場合、衝突するのは特性自体（プレリュード内のアイテムの名前）ではなく、その特性によってスコープに持ち込まれたメソッドです。 たぶん、私たちができる同様の微調整がまだいくつかあるかもしれませんが、それはもっと微妙です。

@SimonSapin TryFrom / TryInto安定化の現在の計画は何ですか？ 4月29日に元に戻される以外に具体的なものは見つかりませんでした。

@nayatoそれ自体がhttps://github.com/rust-lang/rust/でブロックされている、決してタイプしないhttps://github.com/rust-lang/rust/issues/35121を安定化することでブロックされます発行/ 49593。

@SimonSapinneverタイプはここでのみ使用されます。 その実装なしでTryFromを安定させ、安定しないときに着陸させることはできますか？ TryFromは、 Tryと同等であることを除けば、非常に重要なインターフェイスです。

残念ながら違います。 特性が安定し、crates.ioライブラリがたとえばTryFrom<Foo> for Barを実装する機会があり、その一方でFrom<Foo> for Barもある場合、このブランケットimplを追加することは重大な変更になります。オーバーラップします。

これまでの決定は、この方法で$＃ TryFromをFromと「互換性がある」ようにすることは、安定化をブロックするのに十分重要であるというものでした。

おそらく素朴で愚かな考え：

その間にrustcがError<_, !>のトリガーとなる常時オンのエラーリントを取得し、ユーザーランドでのimplを防ぎ、後でimplを追加できるようにした場合はどうなりますか？

または、任意のエラータイプの不安定なimpl<T: From<U>, U> TryFrom<U> for T 。 トレイトインプルは不安定になる可能性がありますか？

@jethrogbいいえ

これがneverタイプでブロックされる理由を完全に理解しているのかどうかはわかりませんが、それがRustに重要なメカニズムが欠けていることを示唆しています。 将来の定義のために望ましい実装を予約する方法があるはずです。 おそらく、そのメカニズムは不安定にするようなものですが、理想的には、非標準のクレートでも使用できるメカニズムです。 この問題に対して提案された解決策を知っている人はいますか？

このimplのためにブロックされます：

impl<T, U> TryFrom<U> for T where T: From<U> {
    type Error = !;

    fn try_from(value: U) -> Result<Self, Self::Error> {
        Ok(T::from(value))
    }
}

@ rust-lang / libsブロックを解除するために、neverタイプではなくenum Infallible {}に戻ることについてどう思いますか？

私は個人的にenum Infalliable {}を持っていて、後でそれをtype Infalliable = !に変更してもかまいません。

昨日のlibsトリアージ会議でこれについて話し合いましたが、安定化後にそのような変更が大丈夫かどうか、または潜在的な破損のためにそのアイデアをすでに拒否したかどうか、またはその破損がどうなるかを思い出せませんでした。

私たちが覚えていたのは、そのような置換を1つしか実行できないということです。2つのより安定した標準ライブラリの空の列挙型（別々のタイプ）が後で同じタイプになると、両方にimplが含まれるクレートが壊れます。 implがオーバーラップ（または同一）になると。 たとえば、 impl From<std::convert::Invallible> for MyErrorとimpl From<std::string::ParseError> for MyErrorです。

ちなみに、 std::string::ParseErrorがあります。これは、私が知る限り、1.30.0標準ライブラリの唯一の空の列挙型です。 したがって、この計画に他の問題がないと確信できる場合は、次のことができます。

• string::ParseErrorをconvert::Infallibleに移動します
• pub useまたはpub typeを使用して、古い場所に再エクスポートします（これにより違いはありますか？）
• TryFromブランケットインプリメントで使用します
• その後、neverタイプが安定したときと同じリリースで、 string::ParseErrorとconvert::Infallibleの両方を$＃ type _ = !に置き換え、使用された場所で直接!を使用します。
• （オプション）後で、古いエイリアスに対して非推奨の警告を発行します

TryFromプレースホルダー特性を自分のクレートに追加しましたが、RFCと安定化の取り組みの意味を完全に理解していなかったので、 FromのブランケットTryFromに驚いています。 FromとInfallible / !のエラータイプは、これを妨げているものですか？ 安定した標準TryFromと包括的TryInto特性を確立した後、これらの二次的な目標はありませんか？ つまり、 FromからTryFrom $への上昇（目的は完全には理解していません）がなくても、それを必要とするすべてのクレートが追加されなければ、解約率は低くなりませんか？独自のTryFrom ？

TryFromがFromの包括的実装なしで出荷される場合の明らかな問題は、クレートが同じタイプに対してTryFromとFromを実装する可能性があることです（おそらく正確にブランケットimplはありません）、ブランケットimplがlibstdに追加されると壊れます。

考えてみると、専門化による大きな変化ではないでしょうか。

うーん、明らかなことが欠けている場合は、もう一度許してください。 これらの1。5年のRFC /追跡オデッセイとほぼ同じように、ロジックの進行を理解するために実行中のFAQセクションが必要です。 ガイダンスが、間違いのない変換に対してのみFromを実装し、間違いのない変換に対してのみTryFromを実装する場合はどうなりますか？ それは、標準でそれを出荷し、木枠を調整することへのより少ない障壁を提供しながら、同様の実用的な最終結果を与えませんか？

はい、 @ glandiumが言ったように、特性がすでに安定した後にブランケットimplを追加することは、重大な変更です。 安定化はまだ準備ができておらず、とにかくこの種の交差点を許可するかどうかは明らかではありません（「厳密により具体的な」方法だけではありません）。

壊れてしまうようなプログラムを書かないというガイダンス（ドキュメント？）を提供することは、壊れた変更を正当化するのに十分ではありません。 破損は間違いなく発生します。

https://github.com/rust-lang/rust/issues/33417#issuecomment -423073898で概説されている計画が実行を開始するには、何が必要ですか？ 助けるために何ができるでしょうか？

これは少しありがたい作業ですが、誰かがこの追跡の問題とhttps://github.com/rust-lang/rust/issues/35121を調べて、その計画に問題があるかどうかを確認できれば役に立ちます。特に、以前のリリースで列挙型が安定した後にenum Infallibleをtype Infallible = !;に置き換えることは、重大な変更になる可能性があるかどうかについて、以前に議論し、忘れていました。

Infallible列挙型は、特性とともに安定化する必要がありますか？ 不安定な状態に保たれていると、誰も名前を付けることができないので、後で!と交換しても問題ありませんか？

@seanmonstarいいえ、 <u16 as TryFrom<u8>>::Errorを使用して参照でき、安定した名前と見なされます。 目撃者：

// src/lib.rs
#![feature(staged_api)]
#![stable(since = "1.0.0", feature = "a")]

#[stable(since = "1.0.0", feature = "a")]
pub trait T1 {
    #[stable(since = "1.0.0", feature = "a")]
    type A;
}

#[unstable(issue = "12345", feature = "b")]
pub struct E;

#[stable(since = "1.0.0", feature = "a")]
impl T1 for u8 {
    type A = E;
}

// src/bin/b.rs
extern crate a;

trait T3 {}

impl T3 for <u8 as a::T1>::A {}
impl T3 for a::E {}

fn main() {}

最初のT3implはエラーを引き起こしません。 2番目のT3implのみが、E0658の「不安定なライブラリ機能の使用」エラーを引き起こします。

それは……うわー、噛まれるように頼むだけ> _ <

私は個人的に、エクスポートされていないモジュールで型を公開するというトリックを使用して、名前のない型を返します。あなたが言ったことを誰かがやった場合、それは破損を意味しますが、私の気持ちは「恥ずべきこと」であり、考慮しません。名前のないタイプを壊すように調整します。

私は個人的に、libstd内のこれらの実際には決してない列挙型のすべてが同じであることを確認してから、それをタイプエイリアスに変更することを気にしません！ それが安定したとき。 私には合理的なようです。

このすべての決して型の混乱とは関係なく、非Copy型でのフォールブル変換の設計上の選択は何ですか？ 失敗した場合に取り戻すことができるように、指定された入力をドロップしないように注意する必要があります。

たとえば、 String::from_utf8を使用すると、エラータイプに所有されている入力Vec<u8>が含まれていることがわかり、それを返すことができます。

// some invalid bytes, in a vector
let sparkle_heart = vec![0, 159, 146, 150];

match String::from_utf8(sparkle_heart) {
    Ok(string) => {
        // owned String binding in this scope
        let _: String = string;
    },
    Err(err) => {
        let vec: Vec<u8> = err.into_bytes(); // we got the owned vec back !
        assert_eq!(vec, vec![0, 159, 146, 150]);
    },
};

したがって、 String: TryFrom<Vec<u8>>の実装を取得する場合、 <String as TryFrom<Vec<u8>>>::ErrorはFromUtf8Errorであると予想されますか？

はい、エラータイプで入力値を「戻す」ことは有効なオプションです。 impl<'a> TryFrom<&'a Foo> for Barで参照することは別です。

ただし、この特定の例では、 TryFrom implが適切かどうかはわかりません。 UTF-8は、Unicodeへのバイトの可能なデコードの1つにすぎず、 from_utf8はその名前にそれを反映しています。

これは少しありがたい作業ですが、誰かがこの追跡の問題と＃35121を調べて、以前に説明し、それ以降忘れてしまったその計画に問題があるかどうか、特にenum Infallibleを置き換えることができるかどうかを確認できれば役立ちます。以前のリリースで列挙型が安定していた後のtype Infallible = !;は、重大な変更になる可能性があります。

今号または＃35121で指摘された具体的な問題はありませんでした。 !が何らかの形で特別であり、抑制されていないタイプではない可能性について1つの懸念がありました。 しかし、PRには懸念はなく、コードレビューのコメントから、列挙型が安定する可能性があったことは明らかです（それは決して起こりませんでしたが）。 これが私が見つけたものへのリンクです。

オリジナルコンセプト
1つの抽象的な懸念
libチームからのゴーサイン

に続く：

44174 9月29日：無謬性タイプを追加

47630 3月14日：ネバータイプを安定させます！

49038 3月22日：Infallibleをneverタイプに変換しました！

49305 3月27日：安定化されたTryFrom

49518 3月30日：プレリュードから削除

50121 4月21日：不安定

!が安定したときのブランケットインプのメモでは、

これはうまくいくでしょうか？

impl<T, U> TryFrom<U> for T
where U: Into<T> {
    type Err = !;

    fn try_from(u: U) -> Result<Self, !> { Ok(u.into()) }
}

impl<T, U> TryInto<U> for T
where U: TryFrom<T> {
    type Err = U::Err;

    fn try_into(self) -> Result<U, !> { U::try_from(self) }
}

このようにして、すべての間違いのない変換（ FromとInto使用）は、対応するTryFromとTryInto implを取得します。ここで、 Errは!です。 From implごとにInto implを取得するのと同じように、 TryFrom implごとに$ TryInto implを取得します。

このように、implを記述したい場合は、 From 、 Into 、 TryFrom 、 TryIntoの順に試してみてください。これらのいずれかが、シナリオで機能します。 、間違いのない変換が必要な場合はFromまたはInto （コヒーレンスルールに基づく）を使用し、間違いのない変換が必要な場合はTryFromまたはTryIntoを使用します（コヒーレンスルールに基づく）。 制約が必要な場合は、フォールブルコンバージョンを処理できるかどうかに基づいて、 TryIntoまたはIntoを選択できます。 TryIntoはすべてのコンバージョンであり、 Intoはすべて間違いのないコンバージョンです。

次に、 impl From<T>またはimpl Into<T>を使用するためのヒントを使用して、 impl TryFrom<T, Err = !>またはimpl TryInto<T, Err = !>に対してリントすることができます。

私たちはすでにこれらの両方の実装を持っています：

https://doc.rust-lang.org/1.31.0/std/convert/trait.TryFrom.html#impl -TryFrom％3CU％3E
https://doc.rust-lang.org/1.31.0/std/convert/trait.TryInto.html#impl -TryInto％3CU％3E

ああ、それらは表示されませんでした（他の実装が多すぎるとドキュメントが乱雑になります）。 変えてもらえますか

impl<T, U> TryFrom<U> for T where    T: From<U>,

に

impl<T, U> TryFrom<U> for T where    U: Into<T>,

これにより、厳密に多くの実装が可能になり、一貫性の理由でIntoしか実装できない人を罰することはないため、 TryFromとFromの自動実装も取得できます。 Intoの包括的implのため、他動詞的に適用されます。

試して、コンパイルされるかどうかを確認し、プルリクエストを送信しますか？

はい、やってみたいです。

From<U> for Tを実装できないが、 Into<T> for UとTryFrom<U> for Tは実装できる場合はありますか？

はい、例えば

use other_crate::OtherType;

struct MyType;

// this impl will fail to compile
impl From<MyType> for OtherType {
    fn from(my_type: MyType) -> OtherType {
        // impl details that don't matter
    }
}

// this impl will not fail to compile
impl Into<OtherType> for MyType {
    fn into(self) -> OtherType {
        // impl details that don't matter
    }
}

これは孤立したルールによるものです。
TryFromとFromは、孤立したルールに関しては同じであり、同様に、 TryIntoとIntoは、孤立したルールに関して同じです。

@KrishnaSannasiあなたの例はコンパイルされます、この遊び場の例を見てください

最新のコヒーレンスルールはこのRFCに記述されており、両方の実装を許可する必要があると思います。

struct MyType<T>(T);

impl<T> From<MyType<T>> for (T,) {
    fn from(my_type: MyType<T>) -> Self {
        unimplemented!()
    }
}

impl<T> Into<(T,)> for MyType<T> {
    fn into(self) -> (T,) {
        unimplemented!()
    }
}

遊び場
ああ、そうですが、汎用パラメーターを追加するとすぐに失敗します。 各implを個別にコンパイルしようとすると、 Fromはコンパイルに失敗しますが、 Intoはコンパイルされます。

この変更が必要なもう1つの理由は、現在、 Into implを記述した場合、それを記述せず、 TryInto implを自動的に取得できないためです。 FromおよびTryFromと矛盾しているため、これは悪い設計だと思います。

TryFrom<U> for TをInto<T> for Uから自動派生させたいが、 From<U> for Tを実装できない場合があるかどうかをもっと尋ねています。 それは私には無意味に思えます。

IntoからTryIntoのブランケットimplが必要なことは確かに理解していますが、残念ながら、型システムでは、他のFromからTryFromと競合するため、このようなブランケットimplは現在許可されていません。 FromからIntoまでのブランケットインプ（または、少なくとも、それは私の理解です）。

これらのユースケースは、RFC @ kjetilkjekaリンクが修正するはずだったものとまったく同じであると私はかなり確信しています。 それが実装された後は、 Intoを実装できるが、 Fromは実装できない場合はありません。

@scottjmaddox IntoがTryInto $を意味するのと同じくらい、 IntoがTryFrom $を意味する必要はありません。 また、 FromとIntoは意味的に同等です。これは、特性システムでそれを表現できないからといって、それが意味するわけではありません。

TryFrom<U> for TはInto<T> for Uから自動派生されますが、 where From<U> for Tは実装できません。

無意味です。 完璧な世界では、区別がなく、タイプ間で変換する特性は1つだけですが、システムの制限により、2つになりました。 安定性が保証されているため、これは変更されませんが、これら2つの特性を同じ概念として扱い、そこから移動することができます。

@clarcharrその場合でも、 IntoがTryIntoを意味し、 TryFromがTryIntoを直接意味するようにする方法はありません。 implsは競合します。 IntoはTryIntoを意味し、 TryFromはTryInto $を意味します。 私が提案する方法は、間接的ではありますが、そうするでしょう。

この変更の主な理由をここに記載したプルリクエストにコメントしました

これは上記の理由ほど重要ではありませんが、このimplを使用すると、すべての間違いのない変換に誤りのある対応物が含まれるようになります。ここで、誤りのあるバージョンのErrタイプは!です。

明確にするために、私はこれらの4つの実装が必要です

• From Into $を意味します（安定性のため）
• TryFrom TryIntoを意味し、 TryInto TryFromを意味します（意味的に同等であるため）
• From TryFrom $を意味します
• Into TryInto $を意味します

それらが直接的に行われるか間接的に行われるかは関係ありません。

または、 TryIntoをエイリアスにすることもできます。

trait TryInto<T> = where T: TryFrom<Self>;

これが実際に機能するかどうかはわかりませんが、十分に単純なようです。

intoメソッドはどこで定義されますか？

@clarcharr @SimonSapinが言ったように、intoメソッドはどこで定義されますか。 トレイトエイリアスはありません。 それは別のRFCである必要があります。 そして、そのRFCでこれをブロックする必要がありますが、これは望ましくありません。

@KrishnaSannasi From => Into From => TryFrom TryFrom => TryInto 4 Into => TryInto Fromを実装するすべてのものがTryIntoに対して2つの競合するimplがあります（1つはFrom => Into => TryIntoから、もう1つはFrom => TryFrom => TryIntoから）。

From => IntoとTryFrom => TryIntoはどちらも重要であるため、 Into => TryIntoを犠牲にする必要があります。 または、少なくともそれは私の理解です。

ええ、私はTryIntoエイリアスが適切に出ているとは思わなかったので、私を無視してください> <

@scottjmaddoxの言うことに同意します。

@scottjmaddox

考えられる誤解を解消するために、 From auto impls TryFromを削除し、 Into auto impls TryFromに置き換えています。

現在、From => Into、From => TryFrom、TryFrom => TryInto、およびInto => TryIntoの4つすべてを使用することはできません。

これは誤りです。提案された実装を見てください。

これです：
From -> Into -> TryFrom -> TryInto

From自動実装Into
Into自動実装TryFrom
TryFrom自動実装TryInto

ひいては、他動詞の自動実装により、
From TryFrom $を意味します（ From自動はIntoを意味し、 Into TryFrom意味するため）
Into TryInto $を意味します（ Into自動はTryFromを意味し、 TryFrom TryInto意味するため）
それぞれに1レベルの間接参照があります（これで問題ないと思います）

だから私の条件はすべて満たされました。
私たちはすべてを持つことができます

Impl | 間接参照のレベル
----------------------- | -------------------
From Into $を意味します| 間接参照なし
TryFrom TryInto $を意味します| 間接参照なし
From TryFrom $を意味します| 1レベルの間接参照
Into TryInto $を意味します| 1レベルの間接参照

From -> Into -> TryInto -> TryFrom
動作しますが、一貫性を維持したいと思います。元のバージョン（上記を参照）は、このバージョンよりも一貫性があります。

用語に関する注意:(私がそれらを使用する場合）

->は自動実装を意味します
auto implは、で入力された実際のimplを参照します。
は、私がこのimplを持っている場合、私もそのimplを取得することを意味します

また、プルリクエストを作成し、すべてのテストに合格したことにも注意してください。つまり、ロジックに穴がないため、これは可能です。 この動作が必要かどうかを議論する必要があります。 一貫性を保つためだと思います（これは非常に重要です）。

プルリクエスト

@KrishnaSannasiああ、今私はあなたのポイントを見る。 はい、それは理にかなっています。提案された変更が問題をどのように解決し、望ましい動作を提供するかがわかりました。 徹底的な説明ありがとうございます！

編集：わかりました、しかし...私はまだ現在のブランケットimplが十分でない理由を理解していません。 おそらく、 Intoを実装できるが、 Fromは実装できない場合がありますか？ それでも、 TryFromを自動導出することは可能ですか？

編集2 ：さて、私は戻って、孤立したルールがFromの実装をどのように防ぐことができるかについてのあなたの説明を読みました。 今ではすべてが理にかなっています。 私はこの変更を全面的に支持します。 孤立したルールが非常に多くの意図しない結果をもたらすことはまだ少しイライラしますが、ここではそれを修正するつもりはないので、物事を最大限に活用することは理にかなっています。

https://github.com/rust-lang/rust/issues/49593が修正され、 never_typeが安定化の候補になったので、@ rust-lang / libsの誰かがこれでFCPを開始する用意がありますか？もう一度？

この機能は、安定化のためにすでにFCPを通過しています。 （提案・完成）あと10日間のコメント期間は必要ないと思います。

neverタイプの安定化PRが到着したら、 TryFrom / TryIntoの（新しい）安定化PRを作成し、そこでrfcbotを使用して、チームメンバーに確実に表示させることができます。

FromStringErrorのような既存の空の列挙型を安定化と並行して!のエイリアスに変更することは可能でしょうか？

@clarcharrはい。 特性は一貫性を意味するため、これを実行できるのは1つのタイプのみです。 幸い、 std::string::ParseErrorしかありません。 （これが、https：//github.com/rust-lang/rust/pull/55148でimpl FromString for PathBufの新しいタイプを追加する代わりに使用した理由です。）

ただし、これはTryFrom / TryIntoとは関係ありません。 これはhttps://github.com/rust-lang/rust/issues/49691/ https://github.com/rust-lang/rust/issues/57012のトピックであり、同じリリースサイクルで発生する必要があるためです。 !の安定化として。

@SimonSapinこれが安定する前に、プルリクエスト（＃56796）をマージすることは可能でしょうか？

確かに、私はそれを問題の説明に追加したので、私たちは道に迷うことはありません。

ありがとう！

これを安定版に統合できますか？ これは、CloudABIのargdataの依存関係です。

@mcandreはい。 これは現在https://github.com/rust-lang/rust/issues/57012で待機しており、最近ブロックが解除されました。 TryFromがRust1.33または1.34で成功することを期待しています。

私はこれを待つのにうんざりしていて、（ついに）自由な時間があります。 これを推進するために私ができるコードやドキュメントタイプのものがあれば、私はボランティアで支援します。

56796が統合されました。 だから私たちはそれをチェックすることができます。

@icefoxen現時点でできる最善のことは、これらの特性のドキュメントに関するフィードバック（および変更）を提供することだと思います。 現在、 FromおよびIntoの特性と比較して、それらが少し不足していることがわかります。

ドキュメントに取り組んでいます。 マイナーなロードバンプ： assert_eq!(some_value, std::num::TryFromIntError(()));にしたい。 ただし、 TryFromIntErrorにはコンストラクターとパブリックフィールドがないため、インスタンスを作成できません。 続行する方法について何かアドバイスはありますか？ 今のところ私はassert!(some_value_result.is_err());をやっています。

これが間違った場所である場合は申し訳ありませんが、TryFromIntErrorのドキュメントに誤りがあるようです。実際にはコードがないのにimpl Debug for TryFromIntErrorと表示されます。 コンパイラは、TryFromの使用から結果をアンラップしようとすると、現在エラーを生成します。

これにfmt::Debug implがあることを意味しますか？

@ marco9999

#[derive(Debug, Copy, Clone, PartialEq, Eq)]
pub struct TryFromIntError(());

#[derive(Debug)]属性があります。

うーん、はい、あります...何かが正しく機能していませんか？

error[E0599]: no method named `unwrap` found for type `std::result::Result<usize, <T as std::convert::TryInto<usize>>::Error>` in the current scope
  --> src\types\b8_memory_mapper.rs:67:51
   |
67 |         let address: usize = T::try_into(address).unwrap();
   |                                                   ^^^^^^
   |
   = note: the method `unwrap` exists but the following trait bounds were not satisfied:
           `<T as std::convert::TryInto<usize>>::Error : std::fmt::Debug`

@ marco9999おそらく一般的な制約がありません。 TryFromIntErrorは一部のタイプでのみ使用されますが、Tは次のいずれかになります。

fn foo<T: TryInto<u8>>(x: T) -> u8
where
    <T as TryInto<u8>>::Error: Debug,
{
    x.try_into().unwrap()
}

とにかく、これは少し話題から外れています、みんなごめんなさい。 IRCは、これらの質問をするのに適した場所かもしれません。

assert_eq!(some_value, std::num::TryFromIntError(()));したい

@icefoxen TryFromIntErrorに関連付けられた有用な値がないため、このようなアサーションにはあまり価値がないようです。 Result<_, TryFromIntError>があり、それがErrの場合、他に価値はありません。

assert!(some_value_result.is_err());

これは私には合理的なようです。

相互参照： https ：//github.com/rust-lang/rust/pull/58302

@glaebhoerlに感謝します。

ブロッキングバグが修正されたため（https://github.com/rust-lang/rust/issues/49593）決してタイプが安定しないことを期待していましたSoon®https ：//github.com/rust-lang/ rust / issues / 57012そしてこれのブロックを解除します。 ただし、新しい問題（https://github.com/rust-lang/rust/issues/57012#issuecomment-460740678）が発生しており、別の問題（https://github.com）についてもコンセンサスがありません。 / rust-lang / rust / issues / 57012＃issuecomment-449098855）。

先週のlibsミーティングで、私は再びアイデアを持ち出しました。 TryFromを安定させるために、 https： //github.com/rust-lang/rust/issues/33417#issuecomment-299124605で@scottmcmによって最初に提案されたと思います。 TryFromとTryIntoは、never型なしで、代わりに空の列挙型を持ち、後で!のエイリアスにすることができます。

前回これについて話し合ったとき（https://github.com/rust-lang/rust/issues/33417#issuecomment-423069246）、前回これを行わなかった理由を思い出せませんでした。

先週、 @ dtolnayは問題を思い出させました。 !が完全な型になる前に、関数のreturn型の代わりに、それが決して返されないことを示すためにすでに使用できます。 これには、関数ポインタ型が含まれます。 したがって、 https：//github.com/rust-lang/rust/pull/58302がこのサイクルに到達すると仮定すると、このようなコードはRust1.34.0で有効になります。

use std::convert::Infallible;
trait MyTrait {}
impl MyTrait for fn() -> ! {}
impl MyTrait for fn() -> Infallible {}

fn() -> !とfn() -> Infallibleは2つの異なる（ポインター）タイプであるため、2つのimplはオーバーラップしません。 しかし、空の列挙型をpub type Infallible = !;型エイリアスに置き換えると（ !が完全な型になると）、2つのimplがオーバーラップし始め、上記のようなコードが壊れます。

したがって、列挙型をエイリアスに変更することは、重大な変更になります。 原則として、標準ライブラリでは許可しませんが、この場合、次のように感じました。

• この変更によって壊れたコードを作成するために邪魔をしなければならないので、実際には起こりそうにないようです
• 時が来たら、クレーターを使用して追加の信号を取得します
• 破損が十分に重大であると判断した場合、never型と、同じ役割を持つ空の列挙型の両方を持つことは、私たちが生きることができる矛盾です。

この議論に基づいて、 https：//github.com/rust-lang/rust/pull/58302を送信しました。これは現在最終コメント期間中です。

58015は、レビュー/マージの準備ができているはずです。

@kennytmすでに安定版で!を参照することはできませんか？ たとえば、次のことを考慮してください。

trait MyTrait {
    type Output;
}

impl<T> MyTrait for fn() -> T {
    type Output = T;
}

type Void = <fn() -> ! as MyTrait>::Output;

これを行った後、 Voidは!タイプを参照します。

これはバグのように見えます。つまり、安定性の保証はバグにまで及びません。 少なくとも＃57012がマージされるまで、never型（ ! ）を任意の容量の型として使用することは依然として不安定です。

どうすればドキュメントを手伝うことができますか？ :-)

ああ、 https：//github.com/rust-lang/rust/pull/58015が上陸したと思いましたが、まだ上陸していません…そこで話し合いましょう。

TryFromトレイトには、引数を消費せずに変換できるかどうかをチェックするメソッドがありますか？

fn check(value: &T) -> bool

消費されない不可能な変換を処理する1つの方法は、消費された変換不可能な値を関連するエラーとともに返すことです。

おっと、これはhttps://github.com/rust-lang/rust/pull/58302によって閉じられているはずです。 閉会しました。

@ o01eg非消費的な変換を行う一般的な方法は、たとえば$＃$ 1 $＃$の代わりにTryFrom<Foo> TryFrom<&'_ Foo>を実装することです。

待ってください...これは、安定した木曜日に着陸するまで実際に閉じるべきではありませんよね？

いいえ、機能を安定させるPRがマスターに到達したときに、追跡の問題をクローズします。

いいえ、通常、安定化または削除がmasterブランチに到達したときに、追跡の問題を閉じます。 その後、追跡するものは何も残っていません。 （新しく報告されたバグが発生しない限り、個別に処理します。）

追跡の問題は、それらを安定させるPRによって閉じられます。 リリースサイクルによっては、安定版がリリースされるまでに最大12週間かかる場合があります。

とった。 皆さん、説明してくれてありがとう！ :)

@gregdegruyは、Rustのバージョンを1.34以降に更新します。