万歳！

ここにこれのWIP実装があります： https ：

現在のステータスは次のとおりです。old-transでビルドされ、使用可能ですが、いくつかの失敗したテストがあります。 トランス中にif (return) {}ようなコードがクラッシュするバグが原因で、一部のテストが失敗します。 他のテストはリンク時間の最適化に関するものであり、私にとっては常にバグが多いので、それらが私の変更と関係があるかどうかはわかりません。

私の現在のロードマップは次のとおりです。

• MIRで動作させます。 これが私がそれを実装し始めた方法であるため、これはうまくいけばそれほど難しくはありませんが、MIRがコンパイル中にセグメンテーションフォールトを構築するという問題がありました。
• コンパイラから廃止された分岐のものを削除します（ FnOutput 、 FnDivergingおよび関連）。
• フィーチャーゲートの後ろに新しいタイプを非表示にします。 これは、機能が無効になっている場合を意味します。
  
  
  
  • !は、戻り位置の型としてのみ解析できます。
  
  
  • 発散型変数のデフォルトは()です。
  
  
• デフォルトの()が特性の解決に使用されたときに、互換性の警告を表示する方法を理解してください。 これを行う1つの方法は、 DefaultedUnitと呼ばれる新しいタイプをASTに追加することです。 このタイプは()ように動作し、状況によっては()に変わりますが、特性を解決すると（ () ）警告が発生します。 このアプローチの問題は、実装のすべてのバグを見つけて修正するのが難しいと思うことです。コードが壊れないようにするために、人々のコードを壊してしまうことになります。

このリストに追加する必要があるものはありますか？ これに取り組んでいるのは私だけですか？ そして、このブランチをメインリポジトリに移動する必要がありますか？

デフォルトの()が特性の解決に使用されたときに、互換性の警告を表示する方法を理解してください。 これを行う1つの方法は、 DefaultedUnitと呼ばれる新しいタイプをASTに追加することです。 このタイプは()ように動作し、状況によっては()に変わりますが、特性を解決するときに警告を発します（ () ）。 このアプローチの問題は、実装のすべてのバグを見つけて修正するのが難しいと思うことです。コードが壊れないようにするために、人々のコードを壊してしまうことになります。

@eddyb、@ arielb1、@anyone_else：このアプローチに関する考察？ 私はほぼこの段階まで進んでいます（私が（非常にゆっくりと）修正しようとしているいくつかの失敗したテストはありません）。

どのような特性を実装する必要がありますか！？ 最初のPR＃35162には、Ordと他のいくつかが含まれています。

!自動的に_all_トレイトを実装するべきではありませんか？

この種のコードはかなり一般的です。

trait Baz { ... }

trait Foo {
    type Bar: Baz;

    fn do_something(&self) -> Self::Bar;
}

Barが実際には存在しないことを示すために、 !がFoo::Barで使用できることを期待します。

impl Foo for MyStruct {
    type Bar = !;
    fn do_something(&self) -> ! { panic!() }
}

ただし、これは!がすべての特性を実装している場合にのみ可能です。

@tomakaそれについてのRFCがあります： https ：

問題は、 !がTraitを実装する場合、 !Traitも実装する必要があることです...

問題は、もし！ トレイトを実装します。トレイトも実装する必要があります。

次に、特殊なケースの! 、特性要件を無視しますか？

@tomaka !は、トレイトに静的メソッドと関連する型/定数を含めることができるため、_all_トレイトを自動的に実装することはできません。 ただし、非静的メソッド（つまり、 Selfを取るメソッド）を持つトレイトを自動的に実装できます。

!Trait 、誰かが!がTrait _と_ !Trait両方を自動実装できると提案しました。 それが正しいかどうかはわかりませんが、否定的な特性はまったく聞こえないのではないかと思います。

しかし、そうです、 !が、まさにこの種の場合に与えた例でBazを自動実装できればいいかもしれません。

発散型変数をデフォルトで() / !に設定するのはいつですか？また、十分な型情報を推測できないというエラーをスローするのはいつですか？ これはどこかに指定されていますか？ 次のコードをコンパイルできるようにしたいと思います。

let Ok(x) = Ok("hello");

しかし、私が得る最初のエラーは「 unable to infer enough type information about _ 」です。 この場合、 _をデフォルトで!に設定するのが理にかなっていると思います。 しかし、デフォルトの動作に関するテストを書いていたとき、型変数をデフォルトにするのは驚くほど難しいことに気づきました。 そのため、これらのテストは非常に複雑です。

なぜこのデフォルトの動作が発生するのか、いつ呼び出されるのかを明確に把握したいと思います。

しかし、私が最初に得るエラーは、「_に関する十分な型情報を推測できない」というものです。 この場合、_をデフォルトで！に設定するのが理にかなっていると思います。 しかし、デフォルトの動作に関するテストを書いていたとき、型変数をデフォルトにするのは驚くほど難しいことに気づきました。 そのため、これらのテストは非常に複雑です。

それは私の意見では非常に良い考えです。 たとえば、デフォルトでOption<!>になるNoneについても同じです。

@carllerche

unit_fallbackテストは確かにそれを実証するための奇妙な方法です。 マクロの少ないバージョンは

trait Balls: Default {}
impl Balls for () {}

struct Flah;

impl Flah {
    fn flah<T: Balls>(&self) -> T {
        Default::default()
    }
}

fn doit(cond: bool) {
    let _ = if cond {
        Flah.flah()
    } else {
        return
    };
}

fn main() {
    let _ = doit(true);
}

return / break / panic!()によって作成された型変数のみがデフォルトで何にでもなります。

正確にいつ発散型変数を（）/にデフォルト設定しますか？ 十分な型情報を推測できないというエラーをいつスローしますか？ これはどこかに指定されていますか？

「指定」を定義します。 :)答えは、コードの外部に書き留められていない特定の操作では、その時点で型がわかっている必要があるということです。 最も一般的なケースはフィールドアクセス（ .f ）とメソッドディスパッチ（ .f() ）ですが、別の例はderef（ *x ）であり、おそらく1つか2つ以上あります。 これが必要とされるのには、ほとんどの場合、まともな理由があります。一般的に言って、進むには複数の異なる方法があり、どれをとるべきかを知らずに進歩することはできません。 （潜在的に、この必要性を一種の「保留中の義務」として登録できるようにコードをリファクタリングすることは可能ですが、そうすることは複雑です。）

fnの最後まで到達すると、定常状態に達するまで、保留中のすべての特性選択操作が実行されます。 これは、デフォルト（i32など）が適用されるポイントです。 この最後の部分は、ユーザー指定のデフォルトタイプパラメーターについて説明しているRFCで説明されています（ただし、RFCは一般に作業が必要です）。

https://github.com/rust-lang/rust/issues/36011
https://github.com/rust-lang/rust/issues/36038
https://github.com/rust-lang/rust/issues/35940

保留中の問題のリストに追加するいくつかのバグがあります。

@canndrewそれらはhttps://github.com/rust-lang/rust/issues/12609に少し似てい

少年、それは古いバグです！ しかし、はい、私の＃36038はその複製だと思います（以前どこかで見たことがあると思いました）。 !は、それが修正されるまで、プライムタイムで実際に検討できるとは思いません。

!がパターンマッチングの網羅性に影響を与える予定ですか？ 現在の、おそらく間違った動作の例：

#![feature(never_type)]

fn main() {
    let result: Result<_, !> = Ok(1);
    match result {
//        ^^^^^^ pattern `Err(_)` not covered
        Ok(i) => println!("{}", i),
    }
}

@tikueはい、それは上記のバグの1つです。

@lfairyおっと、上部のチェックボックスに表示されていなかったため、表示されませんでした。 ありがとう！

From<!> for TとAdd<T> for ! （出力タイプは! ）を実装する計画はありますか？ 私はそれが本当に奇妙な特定の要求であることを知っています-私はこのPRで両方を使おうとしています。

From<!> for T間違いなく。 Add<T> for !はおそらくlibsチームが決定することですが、私は個人的に!が論理的で標準的な実装を持つすべての特性を実装する必要があると思います。

@canndrewありがとう！ 私はすべてのタイプのサブタイプであるscalaのNothingトレイトに慣れているので、値が表示されるほとんどすべての場所で使用できます。 しかし、 impl All for !などがさびの型システムに与える影響、特に負の特性限界などを理解したいという願望には間違いなく共感します。

https://github.com/rust-lang/rfcs/issues/1723#issuecomment -241595070によると、 From<!> for Tは一貫性の問題があります。

そうそう、そうだ。 私たちはそれについて何かをする必要があります。

トレイトインプが他のトレイトインプルによってオーバーライドされることを明示的に述べることができれば、それは良いことです。 何かのようなもの：

impl<T> From<T> for T
    overridden_by<T> From<!> for T
{ ... }

impl<T> From<!> for T { ... }

これは専門分野でカバーされていませんか？ 編集：これはラティスの実装ルールだと思います。

無人タイプの特別なサポートを可能な限り回避することは実行可能な代替手段ですか？

これらすべてのmatch (res: Res<A, !>) { Ok(a) /* No Err */ } 、 Result特別なメソッドは、機能のための機能のように非常に工夫されているように見え、労力と複雑さの価値がないようです。
!は@canndrewのペット機能であり、彼はそれをさらに開発したいと思っていることを理解していますが、最初から進むのは間違った方向であり、＃12609はバグでもありませんか？

@ petrochenkov ＃12609は、Neverタイプの特別な機能ではありません。 明らかに到達不能なコードを検出するのは単なるバグ修正です。

@petrochenkov !を忘れて、列挙型を見てください。

2つのバリアントを持つ列挙型がある場合、2つのケースで一致させることができます。

enum Foo {
    Flim,
    Flam,
}

let foo: Foo = ...;
match foo {
    Foo::Flim => ...,
    Foo::Flam => ...,
}

これは、2つだけでなく、任意のnで機能します。 したがって、バリアントがゼロの列挙型がある場合は、ケースなしで一致させることができます。

enum Void {
}

let void: Void = ...;
match void {
}

ここまでは順調ですね。 しかし、ネストされたパターンで一致させようとするとどうなるか見てみましょう。 これは、 Result内の2つのバリアントの列挙型でのマッチングです。

enum Foo {
    Flim,
    Flam,
}

let result_foo: Result<T, Foo> = ...;
match result_foo {
    Ok(t) => ...,
    Err(Flim) => ...,
    Err(Flam) => ...,
}

内側のパターンを外側のパターンの内側に拡張できます。 Fooバリエーションは2つあるため、 Errには2つのケースがあります。 ResultとFooを照合するために、個別のmatchステートメントは必要ありません。 これは、任意の数のバリアントを持つ列挙型で機能します..._ゼロを除く_。

enum Void {
}

let result_void: Result<T, Void> = ...;
match result_void {
    Ok(t) => ...,
    // ERROR!
}

なぜこれが機能しないのですか？ 私はこれを修正することを無人タイプの「特別なサポート」を追加することとは呼びません、私はそれを矛盾を修正することと呼びます。

@petrochenkov多分私はあなたが言っていることを誤解しました。 ＃12609スレッドで説明されている2つの質問があります。

（0）このコードのコンパイルを許可する必要がありますか？

let res: Result<u32, !> = ...;
match res {
    Ok(x) => ...,
}

（1）このコードのコンパイルを許可する必要がありますか？

let res: Result<u32, !> = ...;
match res {
    Ok(x) => ...,
    Err(_) => ...,
}

現在実装されているように、答えはそれぞれ「いいえ」と「はい」です。 ＃12609は特に問題自体で（1）について話しますが、私が答えたとき私は（0）を考えていました。 答えはどうあるべきかというと、（0）は間違いなく「はい」だと思いますが、（1）についてもわかりません。

@canndrew
それは関係なく、無人の種類、（1）すなわち到達不能パターン、糸くずやないハードエラーをすることが合理的であり、 RFC 1445は、これが役立つことができる理由の多くの例が含まれています。

（0）については、多かれ少なかれあなたの説明に納得しています。 このスキームがコンパイラーのパターンチェックの実装に自然に依存し、追加するよりも多くの特別なコードを削除するのであれば、私は完全に満足しています。

ちなみに、私はここで（0）を修正するためのPRを行いました： https ：

このスキームがコンパイラーのパターンチェックの実装に自然に依存し、追加するよりも多くの特別なコードを削除するのであれば、私は完全に満足しています。

それは、奇妙なことに、そうではありません。 しかし、それはおそらく、エレガントな方法がないというよりも、既存のコードにハッキングした方法のアーティファクトです。

マクロの場合、（1）がハードエラーにならないようにするのが便利だと思います。

（1）はデフォルトでコンパイルする必要があると思いますが、ここと同じlintから警告を出します。

fn a() -> u32 {
    return 4;
    5
}

warning: unreachable expression, #[warn(unreachable_code)] on by default

私たちがそれに取り組んでいる間、 !直面していくつかのパターンを反駁できないようにすることは理にかなっていますか？

let res: Result<u32, !> = ...;
let Ok(value) = res;

網羅的ではないものをエラーと一致させることに同意しますが、到達不能、つまり冗長なパターンは警告だけが理にかなっているようです。

私は腐敗を集めている間、いくつかのPRを座っていました。 これらをレビューするために私にできることはありますか？ おそらくそれらについていくつかの議論が必要です。 ＃36476、＃36449、＃36489について話しています。

発散型（または型理論では「ボトム」型）は空のenum型（または型理論では「ゼロ」型）と同じであると考えることに反対します。 それらは異なるクリーチャーですが、どちらも値やインスタンスを持つことはできません。

私の意見では、ボトム型はリターン型を表すコンテキストでのみ表示できます。 例えば、

fn(A,B)->!
fn(A,fn(B,C)->!)->!

しかし、あなたは言うべきではありません

let g:! = panic!("whatever");

また

fn(x:!) -> !{
     x
}

あるいは

type ID=fn(!)->!;

変数のタイプが!であってはならないため、入力変数のタイプが!あってはなりません。

この場合、空のenumは異なります、と言うことができます

enum Empty {}

impl Empty {
    fn new() -> Empty {
         panic!("empty");
    }
}

それから

 match Empty::new() {}

つまり、 !とEmpty間には根本的な違いがあります。つまり、変数を!型として宣言することはできませんが、 Emptyに対しては宣言できます。 。

@earthengine 2種類の住めないタイプの間にこの（私の目には完全に人工的な）区別を導入することの利点は何ですか？

このような区別がない理由は数多くあります。たとえば、 Result<!, E>を記述できること、これが発散関数とうまく相互作用する一方で、 Resultモナディック演算を使用できることなどです。 mapやmap_err 。

関数型プログラミングでは、空の型（ zero ）は、関数が返されない、または値が存在しないという事実をエンコードするために頻繁に使用されます。 bottom型と言うとき、あなたが参照している型理論の概念は私にはわかりません。 通常、 bottomは、すべてのタイプのサブタイプであるタイプの名前ですが、その意味でbottom 、Rustでは!も空の列挙型もbottomではありません。 しかし、繰り返しになりますが、 zeroがbottom型ではないことは、型理論では珍しいことではありません。

つまり、 !とEmpty間には根本的な違いがあります。つまり、変数を!型として宣言することはできませんが、 Emptyに対しては宣言できます。 。

それがこのRFCが修正していることです。 !は、タイプのように使用できない場合、実際には「タイプ」ではありません。

@RalfJung
これらの概念は線形論理からのものですhttps://en.wikipedia.org/wiki/Linear_logic

この投稿の前のテキストにいくつかの間違いがあるので、私はそれらを削除しました。 私がそれを正しく理解したら、これを更新します。

topは、任意の方法で使用できる値です。

これはサブタイピングでどういう意味ですか？ それはどんなタイプにもなり得るということですか？ それはbottomだからです。

@eddyb私はいくつかの間違いを犯しました、私の新しい更新を待ってください。

このPR（ 1日でマージされました）は、1か月以上レビューされている私のパターンマッチングPRとかなりひどく矛盾しています。 申し訳ありませんが、最初のパターンマッチングPR以降の2番目のパターンマッチングPRはマージ不能になり、2か月間レビューされた後に書き直す必要がありました。

ffsみんな

@canndrew argh 、ごめんなさい。 =（私も今日あなたのPRをr +することを計画していました...

申し訳ありませんが、私は泣き言を言いたくありませんが、これはヘラーが引きずっています。 私は一度に複数のPRを維持しようとするのをあきらめ、今では9月からこの1つの変更を取得しようとしています。 問題の一部はタイムゾーンの違いだと思います-私がベッドにいる間、あなたはすべてオンラインであるため、このことについてチャットするのは難しいです。

例外は型システムの論理的で必要な穴であることを考えると、誰かがそれらを！でより正式に処理する方向に進むことを真剣に考えているのではないかと思いました。

例と参照ポイントとしてhttps://is.gd/4EC1Dkを使用して、それを超えた場合はどうなりますか。

1）パニックになる可能性があるが、エラーや結果を返さない関数を処理します。型シグネチャが暗黙的に-> Fooから-> Result<Foo,!> 2) any結果types would have their Error types implicitly be converted to列挙型AnonMyErrWrapper {Die（！）、Error} `` `
3）以来！ はゼロサイズの広告であり、居住不可能です。タイプ間の変換にかかるコストはゼロであり、下位互換性を持たせるために暗黙的な変換を追加できます。

もちろん、例外が型システムに効果的にリフトされ、それらについて推論したり、静的分析を実行したりできるという利点があります。

これは、技術的な観点からではなくても、コミュニティの観点からは重要なことだと思います。 :)

また、これはおそらく将来のエフェクトシステムと重複します。

@tupshinそれは、少なくとも多くの体操がなければ、画期的な変化です。 わかりやすくしたい場合は、巻き戻しを無効にして「結果」を手動で使用することをお勧めします。 [ところで、この問題は実際にはそのようなことを提起する場所ではありません--- !のデザインはあなたが疑問視しているものではないので、これは純粋に将来の作業です。]

私は、少なくとも重要な体操がなければ、それがどれほど壊れるだろうか、そしてそれが完全に将来の仕事であることについての公正な点を理解しています。 そして、はい、私は計画されていることに非常に満足しています！ これまでのところ、それが行く限り。 :)

@nikomatsakis保留中の問題に関して、これら2つはチェックすることができます

• ＃35162からのコードのクリーンアップ、expr_tyを呼び出す代わりに、戻り位置を介してtypeckをスレッドタイプに少し再編成します
• 試合での無人タイプの扱いを解決する

私はこれで別の亀裂を始めるつもりです：

• （）に依存している人々に警告を実装する方法：その動作が将来変更される可能性があるトレイトフォールバック？

TyTupleにフラグを追加して、発散型変数をデフォルトで作成したことを示し、特性選択でそのフラグを確認することを計画しています。

@canndrew

TyTupleにフラグを追加して、発散型変数をデフォルトで作成したことを示し、特性選択でそのフラグを確認することを計画しています。

OK、すごい！

まあ、多分素晴らしい。 =）そのように異なる2つの意味的に同等のタイプ（ ()と() ）があるのは少し複雑に聞こえますが、これ以上の方法は考えられません。 =（そして、リージョンのおかげで、とにかく多くのコードを準備する必要があります。

つまり、 TyTupleブール値を追加しているということです。

TyTuple(&'tcx Slice<Ty<'tcx>>, bool),

これは、この（ユニット）タプルで特定の特性を選択しようとした場合に警告を発する必要があることを示しています。 これは、別のTyDefaultedUnitを追加するという私の元のアプローチよりも安全です。

うまくいけば、1つの警告サイクルの間だけそのboolを維持する必要があります。

uninitialized / transmute / MaybeUninitialized問題に関して、賢明な行動方針は次のようになると思います。

• mem下の標準ライブラリにMaybeUninitializedを追加します
• uninitialized 、そのタイプに人が住んでいることがわかっていることを確認するチェックを追加します。 それ以外の場合は、これは将来的にハードエラーになるというメモを付けて警告を発します。 代わりにMaybeUninitializedを使用することをお勧めします。
• transmute 、「to」タイプが無人であり、「from」タイプも無人であることを確認するチェックを追加します。 同様に、ハードエラーになる警告を発します。

考え？

網羅性に対する最近の変更については、次のスレッドを参照してください。

• https://internals.rust-lang.org/t/recent-change-to-make-exhaustiveness-and-uninhabited-types-play-nicer-together/4602

&!のセマンティクスについては意見の相違があるようです。 ＃39151以降、 never_type機能ゲートを有効にすると、マッチでは無人として扱われます。

!自動トレイト実装がない場合は、少なくともstdから適切なトレイトを実装すると非常に役立ちます。 void::Void大きな制限の1つは、 std外部に存在することです。つまり、包括的impl<T> From<Void> for Tは不可能であり、エラー処理が制限されます。

少なくともFrom<!>はすべてのタイプに実装する必要があり、 Error 、 Display 、 Debugは!実装する必要があると思います。

少なくともFrom<!>はすべてのタイプに実装する必要があると思います

残念ながら、これはFrom<T> for T implと競合します。

残念ながら、これはFrom<T> for T implと競合します。

少なくとも、latticeimplの特殊化が実装されるまでは。

良い点。 いつかそれが成し遂げられることを願っています。

[T; 0]サブタイプは[!; 0] 、 &[T]サブタイプは&[!]ますか？ 答えは「はい」であるべきだと私には直感的に思えますが、現在の実装ではそうではないと考えています。

[!; 0]は人が住んでいて、 &[!]も住んでいるので、私はノーと言います。 また、今回はサブタイピングを使用していません。

[!; 0]と&[!]両方に無人であってはなりません。どちらのタイプも、値[] （または&[] ）を受け入れることができます。

誰も彼らが無人である、または無人であるべきだとは言いませんでした。

let _: u32 = unsafe { mem::transmute(return) };
原則としてこれは問題ありませんが、コンパイラは「0ビットと32ビットの間で変換する」と文句を言います。

ただし、 ! -> ()変換は許可されています。 これを指摘する特別な理由はありません。 それは矛盾ですが、私はそれに関する実際的または理論的な問題を考えることができません。

私はサブタイピングを期待せず、コンパイラーのあらゆる種類のロジックを複雑にすることを避けるという理由でそれに反対します。 基本的に、リージョンやリージョンバインディングに関係のないサブタイプは必要ありません。

それが実現することが可能であるFn 、 FnMutとFnOnceするために! 、それはすべての入力および出力の種類を超えるジェネリックであるような方法で？

私の場合、ビルド時に呼び出される関数を受け取ることができる汎用ビルダーがあります。

struct Builder<F: FnOnce(Input) -> Output> {
    func: Option<F>,
}

funcはOptionであるため、 Noneを使用するコンストラクターは、 F型を推測できません。 したがって、 fn new実装ではBangを使用する必要があります。

impl Builder<!> {
    pub fn new() -> Builder<!> {
        Builder {
            func: None,
        }
    }
}

ビルダーのfunc関数は、 Builder<!>とBuilder<F>両方で呼び出されるようになります。

impl<F: FnOnce(Input) -> Output> Builder<F> {
    pub fn func<F2: FnOnce(Input) -> Output>(self, func: F) -> Builder<F2> {
        Builder {
            func: func,
        }
    }
}

ここで問題：現在、 Fn*トレイトは!実装されていません。 また、あなたは特性のための一般的な関連付けられている型を（例えば持つことができませんOutputでFn ）。 それでも、 !のFn*トレイトファミリーを、すべての入力タイプと出力タイプで一般的な方法で実装することは可能ですか？

それは矛盾しているように聞こえます。 <! as Fn>::Output単一のタイプに解決する必要はありませんか？

<! as Fn>::Outputは!ですよね？

理論的には<! as Fn>::Outputは!である必要がありますが、現在のタイプチェッカーは関連するタイプが完全に一致することを望んでいます： https ：

@SimonSapin単一のタイプに解決する必要があるので、私は質問をします。 言語の観点からは、それは完全に正しい振る舞いです。 しかし、ライブラリの観点からは、現在の動作が維持されている場合、ジェネリック関数のコンテキストでの!の使用は非常に制限されます。

次のコードが必要です

#![feature(never_type)]

fn with_print<T>(i:i32, r:T) -> T {
    println!("{}", i);
    r
}


fn main() {
    #[allow(unreachable_code)]
    *with_print(10,&return)
}

10ますか？ 現在、何も印刷されません。 または、印刷までreturnを遅らせる他の回避策はありますか？

つまり、前に言ったように、実際には2種類の!タイプがあります。1つは怠惰で、もう1つは熱心です。 通常の表記は熱心な表記を示しますが、怠惰な表記が必要になる場合もあります。

@RalfJungは&returnを使用する以前のバージョンに関心があるので、コードを再度調整しました。 繰り返しになりますが、私のポイントは、後でreturnを遅らせることができるはずだということです。 ここではクロージャを使用できますが、使用できるのはreturn 、 breakやcontinueなどは使用できません。

たとえば、私たちが書くことができればいいでしょう

#![feature(never_type)]

fn with_print<T>(i:i32, r:T) -> T {
    println!("{}", i);
    r
}


fn main() {
    for i in 1..10 {
        if i==5 { with_print(i, /* delay */break) }
        with_print(i, i);
    }
}

5が印刷されるまで休憩が遅れます。

@earthengineいいえ-それは間違いなく何も印刷しないはずです。 !は無人です。つまり、タイプ!の値は作成できません。 したがって、タイプ!値への参照がある場合は、デッドコードブロックの内部にいます。

returnタイプが!ある理由は、分岐しているためです。 returnが「終了」しないため、 return式の結果を使用するコードを実行することはできません。

oO &return書けるとは知りませんreturnのアドレスを取ることを許可されるべきですか？^^

ただし、とにかく、コード内の@earthengineでは、 quit_with_printが呼び出される前に引数が評価されます。 2番目の引数を評価すると、 returnが実行され、プログラムが終了します。 これは、 foo({ return; 2 })ようなものを書くようなものです- fooは決して実行されません。

@RalfJung returnは、 breakやcontinueと同じように、タイプ!の式です。 タイプはありますが、そのタイプは無人です。

!が実装され、1年間毎晩稼働しています。 それを安定化に向けて動かすために何をする必要があるのか​​知りたいのですが。

解決されていないことの1つは、 !返すことができる組み込み関数（つまり、 uninitialized 、 ptr::read 、およびtransmute ）をどうするかです。 uninitialized 、最後に、 MaybeUninitタイプと将来の可能性のある&in 、 &out 、 &uninitを優先して非推奨にする必要があるというコンセンサスがあると聞きました。 Inhabitedトレイトを実装しないタイプのためだけにuninitialized非推奨にすることを提案した以前のRFCがあります。 おそらく、RFCを廃棄して、「非推奨のuninitialized 」および「add MaybeUninit 」のRFCに置き換える必要がありますか？

ptr::read場合、UBのままにしておくのは問題ないと思います。 誰かがptr::readに電話をかけると、彼らは読んでいるデータが有効であると主張していますが、 !場合は間違いなくそうではありません。 たぶん誰かがこれについてもっと微妙な意見を持っていますか？

transmute修正は簡単です-（現在のようにICEingする代わりに）無人タイプに変換するのをエラーにするだけです。 これを修正するためのPRがありましたが

では、現時点でこれらはどこにあるのでしょうか。 （/ cc @nikomatsakis）？ uninitializedを廃止し、 MaybeUninitタイプを追加して、先に進む準備はできていますか？ !で呼び出されたときにこれらの組み込み関数をパニックにした場合、それは!を安定させるのに適した一時的な対策でしょうか？

リストされている保留中の問題もあります：

!に対してどのような特性を実装する必要がありますか？ 最初のPR＃35162には、 Ordとその他のいくつかが含まれています。 これはおそらくT-libsの問題であるため、そのタグを問題に追加します。

現在、かなり基本的な選択肢があります： PartialEq 、 Eq 、 PartialOrd 、 Ord 、 Debug 、 Display 、 Error 。 間違いなくそのリストに追加する必要があるClone以外に、非常に重要なものは他にありません。 これで安定化をブロックする必要がありますか？ 適切と思われる場合は、後でimplを追加することもできます。

(): Traitフォールバックに依存している人々に対して、その動作が将来変更される可能性がある場合に警告を実装するにはどうすればよいですか？

resolve_trait_on_defaulted_unit警告が実装され、すでに安定しています。

強制における!に必要なセマンティクス（＃40800）
どの型変数を!フォールバックする必要があるか（＃40801）

これらは本当のブロッカーのようです。 @nikomatsakis ：実装されるのを待っているこれらについて何をすべきかについて具体的なアイデアはありますか？

!がSyncとSendも実装することは意味がありますか？ エラータイプにSyncおよび/またはSend境界がある場合がいくつかあり、 !を「失敗できない」として使用すると便利です。

@canndrew安全でないコードでそれを禁止することに同意しません。 unreachableクレートは、トランスミュートを使用して無人タイプを作成するため、コードの特定のブランチが発生しないようにオプティマイザーにヒントを与えます。 これは最適化に役立ちます。 そんなテクニックを面白い方法で使って、自分で木枠を作るつもりです。

@Kixunilここでhttps://doc.rust-lang.org/beta/std/intrinsics/fn.unreachable.htmlを使用する方が明確ではないでしょうか。

@RalfJungだろうが、それは不安定だ。 無人タイプへの変換を禁止することは、重大な変更になることを私に思い出させます。

@jsgf申し訳ありませんが、はい、 !は、すべてのマーカー特性（ Send 、 Sync 、 Copy 、 Sized ）も意味します。

@Kixunilうーん、それは残念です。 ただし、 unreachable組み込みを安定させる方がはるかに優れています。

安定化ブロッカーではありませんが（セマンティクスではなくperfであるため）、 Result<T, !>は列挙型レイアウトまたは一致codegenで!の無人を使用していないようです： https ：

これは非常に漠然とした考えなので、ここにドロップすると罪悪感を覚えますが、次のようになります。

チョークは、 !: Trait実装に関する難しい質問のいくつかに答えるのに役立つ可能性がありますか？

@ExpHPそうは思いません。 タイプ/定数が関連付けられておらず、非静的メソッドのみが適切であることがわかっているトレイトに対して、 !: Traitを自動実装します。 それは私たちがそれをやりたいかどうかの問題です。 コンパイラは関連する型/定数に任意の値を挿入し、独自の任意の静的メソッドimplを発明する必要があるため、他の特性の自動実装は実際には意味がありません。

rustcにはすでにresolve-trait-on-defaulted-unitリントがあります。 対応する項目にチェックマークを付ける必要がありますか？

@canndrew関連付けられたタイプを!に設定するのは不健全ですか？

@taralx不健全ではありませんが、有効なコードが機能しなくなります。 次のコードが今日コンパイルされることに注意してください。

trait Foo {
    type Bar;
    fn make_bar() -> Self::Bar;
}

impl Foo for ! {
    type Bar = (i32, bool);
    fn make_bar() -> Self::Bar { (42, true) }
}

@lfairy 「有効な」コードとは何かについてのあなたの意見に依存します。 私にとっては、 !から何も取得できないはずなので、指定したコードが「無効」であることを喜んで受け入れます。

@earthengineあなたが!から「何かを得る」ことができるかどうかは、それとは何の関係もありません。

!タイプから何も取得できないはずの理由はありません。 ただし、 !からは何も取得できません。そのため、プログラマーに決定を強制することなく、 !非静的メソッドを導出できます。

覚えやすいルールは、有効な実装が1つだけあるトレイトを実装することだと思います（スコープ内の!よりも多くの相違を追加するものを除く）。

私たちが使用するものはすべて、それと同等かそれ以上に保守的である必要があります（自動実装も適合しません）。

@ Ericson2314それが何を意味するのかわかりませんが、いくつか例を挙げて

@SimonSapin 「これ以上発散しない」ルールは、 panic!()またはloop { }がないことを意味しますが、すでにスコープ内にあるv: !は問題ありません。 このような表現が除外されているため、多くの特性には、！の可能な実装が1つしかありません。 そのタイプチェック。 （他の人は、1つのimplを除くすべてを除外する非公式の契約を結んでいる可能性がありますが、それらを自動的に処理することはできません。）

// two implementations: constant functions returning true and false.
// And infinitely more with side effects taken into account.
trait Foo { fn() -> bool }

// Exactly one implementation because the body is unreachable no matter what.
trait Bar { fn(Self) -> Self }

数学的に言えば、 !は「初期要素」です。つまり、引数に!が含まれる型シグネチャの場合、実装は1つだけです。つまり、すべての実装が等しい場合です。外から見た。 これは、すべてを呼び出すことができないためです。

これが安定化するのを実際に妨げているのは何ですか？ それはmem::uninitialized状況だけですか、それとも他の何かですか？

@ arielb1 ：＃40800と＃40801もそうだと思います。 これらのステータスを知っていますか？

これについてどのようなドキュメントが書かれていますか、それとも人々はこれのために書くことを計画していますか？ std docs（＃43529、＃43560）のプリミティブ型ページに最近追加されたので、！ そこにページを取得しますか？ まだ更新されていない場合は、参照も更新されるはずです。

asmが発散していることを指定して、次のようなものを記述できるようにする計画はありますか？

#[naked]
unsafe fn error() -> !{
  asm!("hlt");
}

タイプチェッカーをなだめるためにloop{}を使用する必要

編集： core::intrinsics::unreachableは、非常に低レベルのコードでは許容できると思いますが。

@ Eroc33 !がタイプの場合、次のように実行できます。

#[naked]
unsafe fn error() -> ! {
  asm!("hlt");
  std::mem::uninitialized()
}

それまでは、次のことができます。

#[naked]
unsafe fn error() -> ! {
  asm!("hlt");

  enum Never {}
  let never: Never = std::mem::uninitialized();
  match never {}
}

@Kixunil !は、 asm!を使用する必要がある夜間のタイプです。 これは通常、次のように行われます。

#[naked]
unsafe fn error() -> ! {
    asm!("hlt");
    std::intrinsics::unreachable();
}

@Kixunil std::intrinics::unreachable()を使用すると、より簡単に実行できます。これは、前のコードが発散していることを正確に指定します。

@Kixunil上記の議論から、 std::mem::uninitializedが!を返すことができるかどうかは、変更される可能性がありますか？ 私がそれを誤解していない限り？

上記の議論から、 std::mem::uninitializedが!を返すことができるかどうかは、変更される可能性がありますか？ 私がそれを誤解していない限り？

uninitializedは最終的に完全に非推奨になり、ストップギャップとして、 !と一緒に使用すると、実行時にパニックに陥ると思います（ただし、この場合は影響しません）。

また、libcoreのどこかでstd::intrinsics::unreachableを安定させ、 unchecked_unreachableなどの名前を付けてunreachable!マクロと区別する必要があると思います。 私はそのためのRFCを書くつもりでした。

@eddybああ、ええ、 asm!()が不安定であることを忘れたので、 std::intrinsics::unreachable()も使用される可能性があります。

@ tbu-確かに、私は無人タイプを作成するのではなく、それを強く好みます。 問題は、それが不安定であるため、コードのブランチを到達不能として安全にマークすることがどういうわけか不可能である場合、既存のコードを壊すだけでなく、修正不可能にすることです。 そのようなことはRustの評判に深刻な悪影響を与えると思います（特に主要な開発者がそれが安定していると誇らしげに主張していることを考えると）。 私はRustが大好きですが、そのようなことで、Rustが有用な言語であることを再考することになります。

@ Eroc33私の理解では、それを行うことを提案する人もいますが、それは単なる提案であり、明確な決定ではありません。 そして、私はそのような提案に反対します。なぜなら、それは下位互換性を壊し、Rustを2.0にすることを余儀なくされるからです。 それを裏付ける害はないと思います。 人々がバグを心配しているなら、lintがより適切でしょう。

@canndrew uninitializedが非推奨になるのはなぜだと思いますか？ そんなこと信じられない。 非常に便利だと思うので、非常に良い代替品がない限り、そうする理由はわかりません。

最後に、 intrinsics::unreachable()が現在のハッキングよりも優れていることに同意することを繰り返し述べたいと思います。 そうは言っても、十分な代替品が見つかるまで、これらのハッキングを禁止したり、非推奨にしたりすることには反対です。

初期化されていないものの代わりにunion {！、T}を使用します。 あなたは到達不能になることができます
ptr :: read :: <* const！>（）ingおよび他の多くの同様の方法。

2017年8月8日15:58、「MartinHabovštiak」 [email protected]
書きました：

@eddyb https://github.com/eddybああ、ええ、そのasmを忘れました！（）は
不安定なので、std :: intrinsics :: unreachable（）も使用される可能性があります。

@ tbu- https://github.com/tbu-確かに、私は代わりにそれを強く好み
無人タイプを作成します。 問題は、それが不安定であるということです。
コードのブランチを到達不能として安全にマークすることはどういうわけか不可能ですが、そうではありません
既存のコードを壊すだけでなく、修正不可能にします。 そんなことだと思います
Rustの評判を著しく損なう（特に主要な開発者を考慮する）
安定していると誇らしげに主張しています）。 私がRustを愛している限り、そのようなことは
それが有用な言語であることを再考させてください。

@ Eroc33 https://github.com/eroc33私の理解では、一部の人は
それを行うことを提案しますが、それは単なる提案であり、明確な決定ではありません。 そして私
下位互換性が損なわれるため、このような提案に反対します。
Rustを強制的に2.0にします。 それを裏付ける害はないと思います。
人々がバグを心配しているなら、lintがより適切でしょう。

@canndrew https://github.com/canndrewなぜ初期化されていないと思い
非推奨になりますか？ そんなこと信じられない。 とても便利だと思います、
したがって、非常に優れた代替品が存在しない限り、理由はわかりません。
そうする。

最後に、組み込み関数:: unreachable（）に同意することを繰り返し述べたいと思います。
現在のハックよりも優れています。 そうは言っても、私は禁じることに反対します
十分な代替品が見つかるまで、これらのハックを非推奨にします。

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

@nagisaありがとう！ 技術レベルで問題を解決できるようです。

!を戻り型の型パラメーターとして使用できるように、これのサブセットを作成することは可能でしょうか？ あなたが安定した機能を持っているなら今

fn foo() -> ! { ··· }

そして、 ?を使用したい場合、通常の変換を行うことはできません

fn foo() -> io::Result<!> { ··· }

厄介な強制とタイプパラメータのデフォルトの質問はその場合に影響しますか？

match esについては、 https： //public.etherpad-mozilla.org/p/rust-compiler-design-sprint-paris-2017-ucgを参照して

40801チェックマークを付けることができます。

!を安定させる前に、＃43061の修正を試みる必要があります。

never_typeについて言及している未解決のI-unsoundの問題は見当たらなかったので、これについて新しい問題を提出しました：＃47563。 [!; 0]は無人であると想定されているようですが、単純な[]作成できます。

@dtolnayが発行ヘッダーに追加されました

@canndrewお元気ですか？ !使用量のサブセットが安定することを望んでいます（網羅的なものに関するルールを除く）。 でも、今いる場所の糸を失ってしまったので、チャンピオンが必要だと思います。 その人になる時間はありますか？

@nikomatsakis私はこのようなことに取り組む時間を見つけることができると確信しています。 しかし、正確に何をする必要がありますか？ この問題に関連するバグだけですか？

@varkorは、残りの問題を修正するためにすでにPRを開いているよう

別のことですが、実行時にmem::uninitialized::<!>()パニックにしますか（現在はUBが発生します）？ それとも、そのような変更を今のところ残す必要がありますか？ 私は安全でないコードガイドラインのもので何が起こっているのかについて理解していません。

計画はまだhttps://github.com/rust-lang/rfcs/pull/1892だと思いますが、あなたが書いたことに気づきました。 :)

@RalfJung特にそれをブロックしているものはありますか？ 私は付け加えPR今日書くことができますMaybeUninitして非難するuninitialized 。

@canndrew多くのプロジェクトが3つのリリースチャネルすべてをサポートしたいと考えており、 uninitializedは安定版で利用できるため、安定版チャネルで代替品が利用可能になったら、Nightlyで非推奨の警告の発行を開始することをお勧めします。 doc-commentsによるソフトな非推奨は問題ありません。

!を安定させるためのPRを作成しました： https ： @ varkorのPRが残りの未解決の問題を修正するかどうかを確認するのを待つ必要があります。

また、 https： //github.com/rust-lang/rfcs/pull/1699に再度アクセスして、 !エレガントな特性の実装を書き始めることができるようにする必要があると思います。

@canndrew ：そのRFCは受け入れられませんでしたが、 https：//github.com/rust-lang/rust/issues/20021の提案と非常によく似てい

https://github.com/rust-lang/rust/issues/36479もおそらくissueヘッダーに追加する必要があります。

@varkorそれは非常に似ています。 到達不能コードの作業で、このようなコードに到達不能としてフラグが立てられている問題に気づきましたか？：

impl fmt::Debug for ! {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        *self    // unreachable!
    }
}

それは、そのような提案を受け入れる必要があるからです。

@canndrew私が最近提唱していることは、正式なテンプレートはまだ開発していませんが、安定しているものを明確に描写しようとする一種の「要約問題」です。 これはRFC後のレポートと考えることができ、安定しているものとそうでないものの顕著な特徴を箇条書きの形で要約しようとして

この一部は、問題の動作を示すテストケースへのポインターになります。

そんなものを描いてみてもいいと思いますか？ ある種の「アウトライン」が好きなら、私たちは少し一緒にチャットすることができます-または私はそれをスケッチすることを試みることができます。

関連する質問：安定する前にhttps://github.com/rust-lang/rust/issues/46325を解決する必要がありますか？ 多分それは問題ではありません。

@nikomatsakis警告のみの問題が解決されるのを待たないことに投票します。 それは無害です。 それ以上の本当の懸念が現れなければ、私たちは先に進んでそれを安定させるべきだと思います。

@canndrew ： !が安定していれば、不可能な実装を省略できることが大いに必要になると思いますが、そのようなケースを実際に見たことはないと思います。

@nikomatsakis

そんなものを描いてみてもいいと思いますか？ ある種の「アウトライン」が好きなら、私たちは少し一緒にチャットすることができます-または私はそれをスケッチすることを試みることができます。

私は少なくともドラフトを書くことができました、そしてあなたはそれがあなたが考えていたものであるかどうか私に言うことができました。 私は次の数日でそれを成し遂げようとします。

@nikomatsakisこのようなもの？

要約問題- !安定化

安定しているもの

• !は本格的なタイプになり、任意のタイプの位置で使用できるようになりました（ RFC 1216など）。 !タイプは、他のタイプに強制変換できます。例については、 ください。

• 型推論は今に制約のない型変数をデフォルトとします!の代わりに() 。 resolve_trait_on_defaulted_unitリントは廃止されました。 これが発生する例は、次のようなものがある場合です。

  // We didn't specify the type of `x`. Under some circumstances, type inference
  // will pick a type for us rather than erroring
  let x = Deserialize::deserialize(data);
  

  古いルールでは、これは()を逆シリアル化しますが、新しいルールでは、 !を逆シリアル化します。

• never_type機能ゲートは安定していますが、ゲートに使用されていた動作の一部は、新しいexhaustive_patterns機能ゲートの背後にあります（以下を参照）。

安定していないもの

• 無人タイプの徹底的なパターンマッチング。 例えば。

  let x: Result<u32, !> = ...;
  let Ok(y) = x;
  

  このコードは、 Ok(_)が反駁可能なパターンであると文句を言います。 これは、 exhaustive_patterns機能ゲートを使用して修正できます。 この問題の進捗状況については、 RFC1872を参照してください。 この動作がまだゲートされていることを確認するテストケースについては、 https：//github.com/rust-lang/rust/tree/master/src/test/ui/feature-gate-exhaustive-patterns.rsを参照して

安定する前に＃46325を解決する必要がありますか？

このようにすべてのルーズエンドをクリーンアップするのは素晴らしいことですが、実際にはブロッカーのようには見えません。

@canndrew

このようなもの？

うん、ありがとう！ それは素晴らしいことです。

欠落している主なものは、 !がどのように動作するかを示すテストケースへのポインタです。 聴衆は、ラングチームまたは密接にフォローしている他の人々でなければなりません、私はそれが実際には「汎用」の人々をターゲットにしていないと思います。 たとえば、強制が合法である場所、または!を使用できる場所の例をいくつか示したいと思います。 また、徹底的なパターンマッチング（機能ゲートを有効にしない）が引き続き動作することを示す精巣を見たいと思います。 これらはリポジトリへのポインタである必要があります。

@canndrew

このようにすべてのルーズエンドをクリーンアップするのは素晴らしいことですが、実際にはブロッカーのようには見えません。

これは、動作をすぐに変更する新しいコードを有効にすることを意味します（たとえば、 let x: ! = ...は、一部の式では動作が異なると思います）。 可能であれば解決するのが最善のようです。 たぶん、あなたが開いていたPRでそれをハードエラーにすることができ、PRで実行されている既存のクレーターと一緒にそれをまとめることができますか？

@nikomatsakisいくつかのリンクと例を使用して、その要約の問題を再度更新しました。 また、申し訳ありませんが、これに到達するのに時間がかかりました。先週はとても忙しかったです。

たぶん、あなたが開いていたPRでそれをハードエラーにすることができ、PRで実行されている既存のクレーターと一緒にそれをまとめることができますか？

終わり。

@rfcbotfcpマージ

ここで説明するように、 !タイプ、またはその少なくとも一部を安定させることを提案します。 PRはこちらです。

私が欲しいデータの1つは、クレーターの実行です。 https://github.com/rust-lang/rust/pull/47630をリベースしているところです（

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

• [x] @Kimundi
• [x] @alexcrichton
• [] @aturon
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [] @pnkfelix
• [x] @sfackler
• [x] @withoutboats

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

レビューアの過半数が承認すると（そして反対はありません）、これは最終コメント期間に入ります。 このプロセスのどの時点でも提起されていない大きな問題を見つけた場合は、声を上げてください。

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

ああ、私が今覚えているいくつかのこと：

• これを安定させるという考えは、新しい時代にのみ検討する必要があります。 特に、フォールバックルールへの変更は後方互換性がありません-クレーターの実行はフォールアウトにある種の下限を与えますが、それは下限にすぎません。 しかし、新しい時代でない限り、古いフォールバックルールを維持できるかもしれません。
• 次に、ここでの計画の一部は、 !トレイトを実装することが適切な場合のガイドラインもいくつか持つことだったと思います。 TL; DRは、最初に!値を指定せずにトレイトのメソッドが使用できない場合でも問題ないということです。したがって、 ! Cloneを実装しても問題ないと思います。 、しかしDefault実装はそうではありません。 言い換えれば、implを実装するために無差別にpanic!を要求する場合、それは悪い兆候です。 =）

@nikomatsakis新しいエポックでフォールバックルールを変更しても、2015エポックで使用可能なタイプとして!を作成できますか？

@nikomatsakis

これを安定させるという考えは、新しい時代にのみ検討する必要があります。

前回（かなり前のことですが）クレーターランを行ったとき、フォールバックルールの変更によるフォールアウトはごくわずかでした。 また、しばらくの間、変更によって影響を受ける可能性のあるコードに対してリントを行ってきました。

次に、ここでの計画の一部は、 !トレイトを実装することが適切な場合のガイドラインもいくつか持つことだったと思います。

これは!ドキュメントに記載され

@SimonSapin

新しいエポックでフォールバックルールを変更しても、それでも作成できますか？ 2015年の時代に利用可能なタイプとして？

はい

@canndrew

前回（かなり前のことですが）クレーターランを行ったとき、フォールバックルールの変更によるフォールアウトはごくわずかでした。 また、しばらくの間、変更によって影響を受ける可能性のあるコードに対してリントを行ってきました。

うん。 クレーターの言うことを見てみましょう。 しかし、私が言ったように、クレーターは私たちに下限を与えるだけです-そしてこれは一種の「選択的変化」です。 それでも、あなたは正しいと思います。実際のコードに大きな影響を与えることなく、これを変更することで「逃げる」ことができます。

TL; DRは、最初に!値を指定せずに、トレイト内のメソッドが使用できない場合でも問題あり

これは通常のルールです。適切な方法で実装できる場合は、implを追加します。「適切な方法で実装する」とパニックは除外されますが、無効なデータが存在する場合は「exfalso」UBが含まれます。

@ arielb1はい。ただし、 !が存在する場合、何らかの理由でこのようなことについて混乱する傾向があるため、明示的に呼び出す価値があるようです。

到達不能コードなどをlibstdのどこかに安全に表現する方法として文書化されている、安全なメソッドfn absurd(x: !) -> !があると役立つかもしれません。 そのためのRFCがあったと思います...または少なくともRFCの問題： https ：

@RalfJungそのabsurd関数はidentityだけではありませんか？ なぜそれが役に立つのですか？

これは、引数を取らず、非常に未定義の動作であるunsafe fn unreachable() -> !組み込み関数と同じではありません。

ええ、ええ、それはほとんどです。 「終了しない」という意味で!リターンタイプを使用していました。 （ absurdの通常のタイプはfn absurd<T>(x: !) -> Tですが、Rustでも役に立たないようです。）

私は、これが「 !の存在下で、人々はこのようなことについて混乱する傾向がある」のに役立つのではないかと考えていました。

私も間違った問題を抱えているようです...どこかでそのような「exfalso」機能についての議論があると思いました。 私が間違っているようです。

fn absurd<T>(x: !) -> Tはmatch x {}と書くこともできますが、これまで見たことがなければ、それを思い付くのは難しいです。 少なくともrustdocと本で指摘する価値があります。

fnばかげている（x：！）-> Tはx {}と一致するように書くこともできますが、これまでに見たことがない場合は、それを思い付くのは困難です。

そうです、それが私がlibstdのどこかにメソッドを提案した理由です。 しかし、最高の場所がどこにあるかわかりません。

absurdは、高階関数に渡すことができることです。 方法を考えると、これが必要かどうかはわかりません。 wrtで動作します。 しかし、統一。

fn absurd<T>(x: !) -> Tはmatch x {}と書くこともできます

x （AFAIK）と書くこともできます。空のenumがある場合にのみ、 match必要です。

absurd(x: !) -> T関数は、高階関数に渡すのに役立ちます。 たとえば、先物をチェーンするときにこれが必要でした。そのうちの1つはエラータイプ!で、もうTです。 型の式にもかかわらず!に強制することができますTというわけではありません!とTその時々あなたはまだ手動でする必要があり、統一されますタイプを変換します。

同様に、 Resultようなタイプには、 Result<T, !>をResult<T, E>変換する.infallible()メソッドが必要だと思います。

結果のような型には、結果を変換する.infallible（）メソッドが必要です。結果へ。

私はそのようなメソッドがタイプResult<T, !> -> Tを持つことを期待していました。

私はそのようなメソッドがタイプResultを持つことを期待していました-> T。

これはunwrapと同じではありませんか？ Errケースには到達できないため、パニックは最適化されます。

@Amanieu要点は、そもそもパニックがないということです。 パニックリントが欲しいのですが、最適化に頼ると、それはつまずくでしょう。 リントがなくても、 unwrapすると、リファクタリング中にフットガンが追加され、パニックが再びライブコードになることが少なくなります。

unwrapはassert -「ランタイムチェックアヘッド」（IIRCは名前を変更する提案さえありましたが、遅すぎました...悲しいことに）。 実行時チェックが不要で必要な場合は、 infallibleで明示的になります。

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

@rfcbotfcpキャンセル

@aturonと@pnkfelixはチェックボックスを

@cramertjの提案はキャンセルされました。

@rfcbotfcpマージ

https://internals.rust-lang.org/t/psa-tweaks-to-fcp-process/6775

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

• [x] @alexcrichton
• [x] @aturon
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [] @pnkfelix
• [x] @sfackler
• [x] @withoutboats

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

レビューアの過半数が承認すると（そして反対はありません）、これは最終コメント期間に入ります。 このプロセスのどの時点でも提起されていない大きな問題を見つけた場合は、声を上げてください。

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

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

今日の会議でこれについて話し合った。 フォールバックを今変更するのか、それとも新しい時代にのみ変更するのかについて、私はまだ悩んでいます。 ここにさまざまなポイントがあります。

変更による予想される影響はわずかです。 現実的には、これはどちらの方法でも大きな違いはありません。 ここで

そして、それは2つの実際の回帰を残すだけです：oplog-0.2.0（実際には壊れているのはその依存関係bson-0.3.2です）とrspec-1.0.0-beta.4です。 これらは両方とも古いフォールバック動作に依存していますが、幸いなことに、実行時ではなくコンパイル時に壊れています。 これらの箱を修正するためにPRを提出します。

しかし、それはまだ技術的には重大な変更です（そして自発的な変更です）。 ()が非常に不適切な選択であり、コードがそれに依存することは非常にまれであることを除いて、型変数のフォールバックを変更する必要がある特別な理由はありません。 私達はまたこれについて長い間警告してきました。

これは哲学の問題だと思います。過去に、私たちは必要に応じてこのような小さな重大な変更を加えました。 しかし、画期的なメカニズムができたので、技術的に何も壊すことなく、そのような移行を行うためのより原理的な方法が提供されます。 原則として、それを使用する価値があるかもしれません。 一方で、それは時々このような変更を加えるために何年も待つことを意味するでしょう。 そしてもちろん、両方のバージョンを永続的に維持する必要があり、言語仕様などがはるかに複雑になります。

少し引き裂かれていますが、バランスを取りながら、前後にぐらついているので、計画通り「普遍的に変えよう」に傾倒しています。

偏見があることはわかっていますが、フォールバックの動作を変更することは、 dyn Traitやcatchようなものと比較して、より多くのバグ修正として見られます。

さらに、誰かがこれに飛び乗って、「ああ、さびは結局のところ下位互換性を壊します！1.0に達したときの安定性の約束は嘘でした！」と言いたい場合。 次に、この問題に関する非常に思慮深い議論は、実際的な影響がごくわずかであったとしても、決定が軽々しく行われなかったことを示しています。

OK、変更しましょう。

それでは、妥協案として、動作が変更されたことを人々に知らせるエラーについて役立つメモを提供したいと思います。これはもっともらしいと思われます。 アイデアは次のようになります。

• 我々は次のようにエラーが表示された場合は!: Fooいくつかの特性のため、そして形質がために実装されていることを(): Foo 、そして我々は（我々はエラー報告のコードにこの事実を伝えることができます）フォールバックを行っている、我々は追加します追加のノード。

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

一番上の投稿の保留中のチェックボックスはまだチェックされていませんか？ そのリストで取り消されたものはありますか？

@earthengine私が見ている2つは特に関連性があるとは思いません。一番上の項目については、implのセットについては、当面は決定されていると思います。

基本的にはごく最小限のセットになります。

@nikomatsakisここで要約の問題を作成しました： https ：

! !タイプの値に一致するパターンにすることについて検討したことはありますか？ （私はこの問題と元のRFCの問題を簡単に調べましたが、関連するものは何も見つかりませんでした）。

これは、潜在的に!エラータイプから複合エラータイプを作成するStreamFutureなどのタイプに役立ちmap_errで!パターンを使用することにより、将来のある時点でエラータイプが変更された場合、 map_err呼び出しは、何か別のことを行う可能性があるのではなく、コンパイルを停止します。

例として、与えられた

let foo: Result<String, (!, String)> = Ok("hello".to_owned());

これにより、より明確な記述が可能になります

let bar: Result<String, String> = foo.map_err(|(!, _)| unreachable!());

エラーが発生しやすい可能性のある代わりに

let bar: Result<String, String> = foo.map_err(|_| unreachable!());

またはわずかにエラーが発生しにくい

let bar: Result<String, String> = foo.map_err(|(e, _)| e);

編集： https ： !パターンの導入が記載されています。 これは純粋にmatch式のコンテキストですが、クロージャー/関数の引数に一般化されるかどうかはわかりません。

@ Nemo157

作ることを考えたことはありますか？ ！の値に一致するパターンタイプ？

面白い。 計画はそのような武器を省くことだけだったと思います。その場合、将来タイプが変更された場合でも、試合が完全ではなくなるため、エラーが発生します。 !パターンの問題は、それが一致する場合、それは腕が不可能であることを意味することです。これは少し厄介です。 実行する式を指定する必要がないことで、それを説明したいと思います。 それでも、このケースは起こり得ないことを明示的に言う方法があると便利かもしれません。

実際、到達不能なパターン処理を拡張することは、これを解決するための代替方法である可能性があります。 マッチアームがおそらく不可能である場合、アーム内のコードは無視される可能性があります。 それからあなたが持っているとき

fn foo() -> Result<String, String> {
    let bar: Result<String, (!, String)> = Ok("hello".to_owned());
    Ok(bar?)
}

これは今日のように拡張されます（_これが正しい拡張であるかどうかは100％確信できませんが、十分に近いようです_）

fn foo() -> Result<String, String> {
    let bar: Result<String, (!, String)> = Ok("hello".to_owned());
    Ok(match Try::into_result(bar) {
        Result::Ok(e) => e,
        Result::Err(e) => return Try::from_err(From::from(e)),
    })
}

ただし、 Result::Errブランチはタイプチェックされず、今日発生するthe trait bound `std::string::String: std::convert::From<(!, std::string::String)>` is not satisfiedエラーは発生しません。

それはRFC1872が提案していたものと互換性があるとは思いませんが、浅い一致を実行している明示的なアームがあるため、必ずしも!値の有効性に依存しているわけではなく、潜在的にそのブランチがe.0をまったく使用しない限り、関連するブランチを「安全に」実行します。

!はboolような正の型であるため、クロージャ構文を拡張して複数のブランチを許可しない限り、クロージャ引数リストでパターンマッチングを行うことは不可能です。 例えば。 クロージャbool -> u32を（醜い仮想構文） [~ |false| 23, |true| 45 ~] -> u32ように記述できるようにすると、空の型からu32へのクロージャを単純に[~ ~] -> u32と書くことができます。

元の例では、 unreachable!使用を回避するため、 foo.map_err(|(e, _)| e)方が好きですが、 foo.map_err(|_: (!, _)| unreachable!())書くことができます。

!はポジティブタイプです

ポジティブタイプとはどういう意味ですか？

複数のブランチを許可するようにクロージャ構文を拡張せずに、クロージャ引数リストでパターンマッチングすることはちょっと不可能です

引数リストは、たとえば、反駁できないサブパターンをすでにサポートしています。

let foo: Result<String, ((), String)> = Ok("hello".to_owned());
let bar: Result<String, String> = foo.map_err(|((), s)| s);

!パターンを!タイプのすべての0値に一致する反駁できないパターンと見なします。これは、 ()がの1つの値すべてに一致する反駁できないパターンと同じです。 ()タイプ。

私はただ考えます！ ！のすべての0値に一致する反駁できないパターンとしてのパターンタイプは、（）と同じで、（）タイプの1つの値すべてに一致する反駁できないパターンです。

しかし、0！= 1です。;） !照合した後、コードを記述しても意味がありません。たとえば、引数の型が(!, i32)場合、 |(!, x)| code_goes_hereとにかくそのコードは死んでいるので、 xが!要素であることを非常に明確にするために、おそらく|(x, _)| match x {}と書きます。 または、上記でabsurd関数、 |(x, _)| absurd(x)ます。 または多分|(x, _)| x.absurd() ？

@canndrewが上で書いたように、コードを記述できない別の構文を想像することができます。 matchは任意の数の分岐があるため、特に分岐がない可能性があります。ただし、クロージャのケースは1つだけなので、意味のあるパターンは、一致する方法が1つだけのパターンだけです。 0通りではありません。

残念ながら、今はimpl<T> From<!> for T追加できません。 （何か特別なものがない限り、 From<T> for Tと重複しますか？）おそらく後で追加することはできません。 （ !が安定した後のリリースサイクルでは、一部のクレートがFrom<!> for SomeConcreteType実装する場合があります。）

@SimonSapin良い点！ これは多くの点で非常に便利な構成要素であり、私は永遠にそれを失うことを嫌います。 両方のインスタンスを許可するために、1回限りのハックを真剣に検討したいと思います。 それらは重複する場合に意味的に一致するため、「操作上の矛盾」はありません。

一回限りのハックを真剣に検討したい

その後、そのハックは数日以内に着陸する必要があります。 （またはベータ期間中にバックポートされます。）

@SimonSapinこのようなハックをどれだけ迅速/簡単に追加できますか？ From<!> for Tを持てないのは本当に残念です。

または、 From<!> for SomeConcreteType実装に対して警告をすぐに出すこともできます。

わからない、ハックが何であるかによる。 交差点に3分の1がある場合、トレイトの特殊化によって2つの重複するimplを有効にできると思いますが、そのためには、トレイトを公に「特殊化」する必要がありますか？

残念ながら、専門分野：

• From::fromをdefault fnに変更する必要があります。これは、stdの外部で「表示」されます。 特殊化が不安定である限り、標準特性でそれを実行したいかどうかはわかりません。
• RFC 1210で受け入れられているように、特に私が考えていた言語機能をサポートしていません（交差点の3番目のimplを作成することにより、どちらも他方よりも具体的でない2つの重複するimplを明確にします）。

ここで、2つのimplはまったく同じことを行います。 コヒーレンスチェックをオフにするだけでは、どのimplが使用されているかを判断するのは困難です。これは通常、非常に不健全ですが、この場合は問題ありません。 たとえば1つの結果を期待して、コンパイル中にパニックを起こす可能性がありますが、それを回避することはできます。

言い換えれば、ありがたいことに、これは専門分野のいずれかを促進するよりもはるかに簡単だと思います。

この「関係するすべての実装が到達不能な場合に任意の重なりを許可する」という考えを形式化するための既存のRFCはありますか？ 検討すべき興味深いアプローチのようです。

私が知っていることではありません。 振り返ってみると、impl自体は到達不能ではありませんが、内部のメソッドはすべて呼び出し不可能です（常に「呼び出し可能」であるため、関連する型や定数は含まれません）。 そのようなことでハッキングがブロックされていると思われる場合は、すぐに書くことができると思います。

原因となる可能性のある問題＃49593に言及するだけです！ ファインダビリティを向上させるために、再び不安定になります。

!が安定した後、 T: From<!>以外の他のimplを追加できないのでは! implとは異なり、そのようなすべての合理的なimplを処理するように努める必要があります。

このコメントからのクロスポスト：

疑問に思っていたのですが、（）へのフォールバックを変更する必要がある理由の典型的な例は何ですか？ つまり、（）にフォールバックし続けたが、それでも！を追加した場合、そのような問題は確実に回避され、！にフォールバックします。 「ライブ」コードに影響を与える型変数へのフォールバックが発生する場合があることを考えると、は最適ではありません（もちろん意図はありませんが、私たちが見つけたように、リークを防ぐことは困難です）。

その変更の結果としていくつかの後退がありました、そして私はそれに完全に満足していないと言わなければなりません：

• @SimonSapinは、安全でないコードがどのように回帰して不健全になったのかを説明しています。 これは、バインドされていない型パラメーターが!フォールバックしたため!た。 これは現在のスキームの既知の障害であり、 match foo { P1 => ..., P2 => return }がある場合に発生します。 戻り値は、他のアームと統合される「 !型変数へのフォールバック」を生成します。 修正するのは非常に難しいことが証明されています。 たとえば、 https ： ください。
• @mitsuhikoがこのコメントを上げ

（この点に関するlang-teamディスカッションにノミネートします。）

会議中に、ここでいくつかのオプションを撤回しました。主に、一部のコーナーケースで既存のコードのセマンティクスが変更されるため、変更を加えることに抵抗を感じています。新しいルールの優れているかどうかは明らかではありません。 しかし、ほとんどの場合、より完全な議論ができるように、各デザインの長所/短所をもう一度収集してみるのは素晴らしいことだと思いました。 ユースケースと落とし穴のリストを見たいのですが。 @cramertjは、Ok(33)は、今日のようにエラーが発生するのではなく、 Result<i32, !>にフォールバックするタイプを持っています。 私は、彼らが、その後のフォールバックを保つことを言っていたと思いますreturnと() （彼らは直交しているが）、このような変更と矛盾するだろう、と道競合を作成することがあります。 これは公平です。

Errフィードバック（＃40801）の課題は、次のようなエッジケースもあることです。

let mut x = Ok(22);
x = Err(Default::default());

ここで、 xのタイプは、最終的にResult<T, !>推測されます。

!フォールバックがライブコードに「影響を与えた」かどうかを判断できるかどうか（そしておそらく警告？またはエラー？）を試してみる必要があった別の計画を思い出しました-これは非常に難しいことがわかりましたが、実際に多くのケース@SimonSapinのケース）。

新版でこのフォールバックを完全に取り除くことができるかどうかについての議論もありました。 多くのマクロが壊れるのではないかと思いますが、試してみる価値はあるでしょうか。

参考までに、この機能により1.26でリグレッションが発生しました：＃49932

（https://github.com/rust-lang/rust/issues/35121#issuecomment-368669041に従ってラベルを設定します。）

!への強制に関するチェックリスト項目は、この問題を参照するのではなく、 https：//github.com/rust-lang/rust/issues/50350を指している必要があり

これをできるだけ早く安定させたい場合、私のエネルギーを向けるのに最適な場所はどこですか？

@remexre安定化を元に戻す問題の最も良い説明は、 https： //github.com/rust-lang/rust/issues/49593にあると思います。

したがって、実行可能な解決策は、のサブタイプとして特殊なケースのBoxを使用することです。
箱？ この方法で処理できないオブジェクトセーフ特性はありますか？

2018年7月8日、日曜日の午前8時12分にRalfJungの[email protected]は次のように書いています。

@remexrehttps ：//github.com/remexre私は
安定化を元に戻すことにつながる問題は＃49593にあります
https://github.com/rust-lang/rust/issues/49593

—
あなたが言及されたのであなたはこれを受け取っています。

このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/35121#issuecomment-403286892 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AEAJtcnsEaFmHrrlHhuQeVOkR8Djzt50ks5uEgVLgaJpZM4JYi9D
。

>>

ありがとう、
ネイサン

その議論は実際にはhttps://github.com/rust-lang/rust/issues/49593に入る必要がありますが、その重要な部分はBox::<T>::newはT: Sizedが必要ですが、そのnew呼び出されたT = Error （特性DST）を持っていると推測されます。

特別な場合の優雅さ以外に、特別な場合のBox::newに問題はありますか？

Box::new : T -> Box<U>
where T <: U,
      T: Sized

また

Box::new : T -> Box<U>
where Box<T> <: Box<U>,
      T: Sized

まず、 !のサイズを考える必要があります。 MathemticansはInfようなものを提案しますが、実際にはusize::MAXになるため、このタイプにスペースを割り当てる試みは失敗するか、少なくともpanicます。

!がSized場合、 Box::new(x as !)コンパイルを妨げるものは何もありませんが、実際にはメモリモデルがないため、これは基本的にpanic!別の方法です。 usize::MAXバイトを割り当てます。

!がZSTであるのに対して、無限/ usize::MAXサイズを持つべきであることは私には明らかではないようです。

use std::mem::size_of;
enum Void {}
fn main() { println!("{}", size_of::<Void>()); }

現在は0です。

理由は、レンダリングされたテキストで説明されました。

bool ：2つの有効な値=> log（2）/ log（2）= 1ビット
() ：1つの有効な値=> log（1）/ log（2）= 0ビット
! ：0有効な値=> log（0）/ log（2）= Infビット

関連する理論に精通していない人として、私は、理論モデルの優雅さを追いかけて実用性を損なう限り、 log(x)/log(y)公式に固執していると思います。 （別名、自分の利益には賢すぎる）

直感的には、 !もゼロサイズである必要があるようです。理由は次のとおりです。

• bool ：型システムに加えて、2つの有効な値を区別するためのスペースが必要=> log（2）/ log（2）= 1ビット
• () ：1つの有効な値を区別するためにスペースが必要=>型システム以外にスペースは必要ありません
• ! ：有効な値を区別するためにスペースが必要=>型システム以外にスペースは必要ありません

ええと、それは実際には無限大です。これは、！を配置するので理にかなっています。 フィールドを構造体に変換すると、基本的に構造体が！に変換されます。 同様に（c + -inf = -inf）。 したがって、usizeを扱っているので、0はそれを表すために必要な最も近い値です。 （rustcでの実際の実装でも-infを使用していると思います）。

直感的には、 !もゼロサイズである必要があるようです

!は、そのタイプで作成される値がないため、サイズはまったく必要ありません。 それは無関係な質問です。

0有効な値=> log（0）/ log（2）= Infビット

log（0）は未定義です。 それは無限ではありません。

一方、 usize::MAXサイズを持つことは、無人を強制するための厄介な方法です。 同意？

@CryZe @varkor

これは、私が妥当性を推論しようとしていた概念とも一致します。私の直感では、 !を「まったく別のレベルのZST」と見なしたいと考えています。 （つまり、 !は型システムに対するものであり、 ()はメモリ割り当てに対するものです。）

@CryZe
数式-Inf + c == -Infは理にかなっていますが、 -Infを0usizeに置き換えると、それ以上保持されなくなります。

一方、算術演算が「上限付き」の場合、オーバーフローはusize::MAX計算され、 usize::MAXは数式に完全に適合します。

脳モデル：タイプ!オブジェクトがある場合、それを含む構造体を割り当てるには、 !よりもさらに大きな構造体が必要ですが、イメージできる最大の構造体サイズはusize::MAX 。 したがって、必要なスペースはまだusize::MAXです。

void型が含まれ、あらゆるタイプの理由だけではなく、 "クランプ"のサイズ（ ! 、またはユーザー定義enum Void {} ）とsize=0,alignment=0 ？ これは私にははるかに意味的に賢明なようです...

@remexre
これは機能しないためです。 例： sizeof(Result<usize,!>) == sizeof(usize) 。

ええと、 Result<usize, !>は!直接含まれていません。 sizeof(Result::Ok(usize)) == 8 、 sizeof(Result::Err(!)) == 0

いいえ、 sizeof(Result::Err(!)) == usize::MAX 、私の提案ではResult::Err(!) :: Result<!,!>です。

ルールは次のようになります。 enumの場合、 !のサイズは他のすべてのサイズ値よりも小さいと見なされますが、 structs場合、これは画像化できる最大サイズです。

結論：

• !はDSTではありません。 DSTはSizedはありません。サイズがないためではなく、サイズ情報が非表示になっているためです。 しかし、 !私たちはそれについてすべて知っています。
• !サイズを設定する必要があるため、 Box::new(x as !)は少なくともコンパイルできるようにする必要があります。
• struct sが含ま! 、それがあるかのように寸法決めされるべきである! 、 enum sが含ま!バリアントにdirectallyのような大きされるべきですそのバリアントが存在しない場合。

sizeof(!)==0またはsizeof(!)==usize::MAXいずれかを検討する場合、上記を可能にするためにいくつかの特別な算術を導入する必要があります。

sizeof(!)==0 ：構造体、 0 + n = 0 ：心配：、列挙型、 max(0,n) = n ：赤面：。
sizeof(!)==usize::MAX ：構造体、 usize::MAX + n =usize::MAX ：neutral_face ：、列挙型、 max(usize::MAX,n) = n ：フラッシュ：。

ただし、 usize::MAXにはメリットがあります。実際のシステムでは不可能なため、 unsafeであっても、そのようなオブジェクトを構築しようとする試みを技術的に防止します。

ただし、usize :: MAXには利点があります。実際のシステムでは不可能なため、安全でないオブジェクトであっても、そのようなオブジェクトを構築しようとする試みを技術的に防止します。

私があれば、意味unsafe ：ペテンが許可されている*transmute::<Box<usize>, Box<!>>(Box::new(0))私に取得!関わらず、そのサイズの。 usize::MAXは、誰かがstd::mem::zeroed<!>()を実行しようとすると、コンパイラがエラーになる可能性が高くなると思いますが、数学ではなく、その危険なコードを書いている人に責任を負わせます上記の奇妙さ。

サイズが_actually _ 0 ! MAXでも-INF -saturated-to-0でもない）は、部分的な初期化を処理するために必要であることに注意してください。 https://github.com/rust-lang/rust/issues/49298#issuecomment -380844923にありhttps://github.com/rust-lang/rust/pull/50622に実装されています）。

これがどのように機能するかを変更したい場合は、そのための新しい問題またはPRを作成してください。 これは場所ではありません。

@remexre

Box::new : T -> Box<U>
where T <: U,
      T: Sized

Boxは（ほとんど）ライブラリタイプであり、そのnewメソッドはsrc/liballoc/boxed.rs Rust構文で定義されています。 説明では、Rustに存在しない<:演算子を想定しています。 これは、Rustのサブタイプがライフタイムパラメーターを介してのみ存在するためです。 もっと読んだり見たりしたい場合：

• https://doc.rust-lang.org/nomicon/subtyping.html
• https://www.youtube.com/watch?v=fI4RG_uq-WU

!任意の型に強制することができますが、これはどのタイプのものよりも弱いです。 （たとえば、 Vec<&'static Foo>はどの'aでもVec<&'a Foo>ですが、 Vec<!>からVec<Foo>への暗黙の変換はありません：http：/ /play.rust-lang.org/?gist=82d1c1e1fc707d804a57c483a3e0198f&version=nightly&mode=debug&edition=2015）

unsafeモードで適切だと思うことは何でもできるという考えだと思いますが、賢明に行わないとUBに直面する必要があります。 !の公式サイズがusize::MAX場合、これは、このタイプがインスタンス化されないようにユーザーに十分に警告する必要があります。

また、アラインメントについても考えていました。 無人タイプのサイズがusize::MAX場合、その配置もusize::MAXに設定するのが自然です。 これにより、有効なポインタがnullポインタに制限されます。 しかし、定義上、nullポインターは無効であるため、このタイプの有効なポイントすらありません。これは、この場合に最適です。

@ScottAbbey
Box::new(x as !)問題がないことを確認するためにこの問題に焦点を当てているので、これを安定させることができます。 提案された方法は、 !サイズを持たせることです。 ZSTが標準の場合は、問題ないはずです。 私はもう議論していません。 sizeof(!)==0が実行できるように実装するだけです。

その配置を設定するのも自然です:: MAX

usize::MAXは2の累乗ではないため、有効な配置ではありません。 また、LLVMは1 << 29を超えるアライメントをサポートしていません。 そして、 !あるため、とにかく大きなアライメントを持つべきではありませんlet x: (!, i32); x.1 = 4; 、スタックの4バイトのみを取る必要があり、ギガバイトまたは-以上ではありません。

続行する場合は、このディスカッションの新しいスレッド@earthengineを作成してください。

ここで発生する問題は、 Box::new(!)がBox<$0>であり、 Box<Error>予想されることです。 十分な型注釈があれば、 Box<$0>をBox<Error>に強制変換する必要があります。これにより、後で$0デフォルトで!ます。

ただし、 $0は型変数であるため、強制は行われず、 $0 = Error取得します。

物事を修正するためのハッキーなオプションの1つは、制約$0: Sized （サブタイプに続く？）があることを見つけ、それにキー設定された強制を挿入することです。これにより、 Boxが引き続きタイプで呼び出されます。

我々はすでに検出するため、このような何かFnこれは、このようなストレッチではありませんので、閉鎖中を。 まだ醜い。

それだけです。強制中に$0: Unsize<Y>の形式の義務が発生した場合、 Yは間違いなくサイズ設定されておらず、 $0は間違いなくサイズ設定されています。それをあいまいさとして扱うのではなく、それを「OK」として扱い、サイズのない強制を続行します。

@ arielb1

では、これはBox::new(())からBox<Debug>への強制とどのように違うのでしょうか。 std::error::ErrorはDebugような特性であり、 [u8]ようなタイプではありません。 std::io::Errorはタイプですが、 Sizedです。

次のような問題は発生しません。

use std::fmt::Debug;

fn f(x:()) -> Box<Debug> {
    Box::new(x)
}

fn main() {
}

@earthengineこの問題とコードの違いは次のとおりです。

| 書かれた| Box::new(!): Box<Debug> | Box::new(()): Box<Debug> |
| ------ | ------ | ------- |
| 実行済み| Box::new(! as Debug): Debug | (Box::new(()) as Box<Debug>): Debug |

基本的に、 !は何にでも強制変換できるため、 Box::new呼び出す前にDebugに強制変換されます。 これは()オプションではないため、2番目のケースでは問題はありません。 Box::new後に強制が発生

@RalfJung

私の脳のモデルは、DSTは野生では存在できないというものです-それらはいくつかのより具体的なタイプから来なければなりません。 これは、DSTをパラメーター位置で許可する場合にも当てはまります（戻り位置ではない場合）。 とは言うものの、実際の値がすでにポインターの後ろに配置されるまで、それが!であっても、DSTに合わせることができないはずです。

たとえば、以下はコンパイルしないでください。

let v: str = !;
let v: [u8] = !;
let v: dyn Debug = !;

!を既存のRust式に置き換えてコンパイルすることができないという理由だけで。

編集

それは（）のオプションではありません

だから誰かが理由を説明できますか？ () as dyn Debugがコンパイルされない場合、 ! as dyn Debugはコンパイルされません。その逆も同様です。 &() as &Debugコンパイルされるので、 &! as &Debugも問題ありません。 () as dyn Debugがいつかコンパイルされる可能性がある場合、今日の問題は()で繰り返されるため、DST RFC実装者はそれを受け入れる必要があり、同じ問題を解決します。 ! 。

!は存在することが不可能であるため、何にでも強制します。 「Exfalsoquodlibet」。 したがって、すべての例をコンパイルする

!も存在できないため、これは「DTSは存在できません」にも違反しません。 :)

() as dyn Debugはコンパイルされません

サイズのない右辺値の計画はわかりませんが、これをコンパイルできると思いますか？
重要なのは、これを!に対して実行する場合、デッドコードでのみ発生する可能性があるため、サイズ変更されていない右辺値を実装する必要がないということです。

ただし、ここで考えられる解決策を示している可能性があります（ @ arielb1も上記で提案したものです）：ターゲットタイプが（既知の）サイズの場合にのみ適用されるように!強制を制限することは可能ですか？ ？ これを行うための適切な理論的理由はありませんが、実用

「DTSは存在できない」と言ったとき、私は構文的に意味します。 たとえば、入力されたローカル変数をstrにすることはできません。

一方、 !は存在できませんが、意味があります。 あなたは書ける

let v = exit(0);

v構文的に!と入力しますが、原因として、バインディングは実行されないため、現実の世界では終了しません。

したがって、理由は次のとおりです。同じ型の式を記述できる場合にのみ、 !を任意の型に強制変換できます。 型が構文的に存在することさえできない場合、それは許可されるべきではありません。

これはサイズなしの右辺値にも当てはまるため、サイズなしの右辺値を取得する前に、サイズなしの右辺値の処理方法がわかるまで、サイズなしの型に!を強制変換することはできません。 そして、その時点でのみ、この問題について考え始めることができます（1つの明白な解決策は、 Box::newがサイズのない値を受け取ることを許可することであるようです）。

たとえば、入力されたローカル変数をstrにすることはできません。

これは現在の実装の制限にすぎません： https ：

@RalfJung

それはここでは問題ではありません。

ここでも、 Box::new(!: $0): Box<dyn fmt::Debug>が$0が型変数である状況にあると仮定します。

次に、コンパイラは$0: Sizedをかなり簡単に推測できます（ $0はT: SizedバインドがあるBox::newの型パラメータに等しいため）。

問題は、コンパイラがBox<$0>をBox<dyn fmt::Debug>に変換するために使用する強制の種類を把握する必要がある場合に発生します。 「ローカル」POVから、2つの解決策があります。

1. CoerceUnsized強制があり、 Box<$0>: CoerceUnsized<Box<dyn fmt::Debug>>必要です。 これは$0 = !有効なプログラムであり、デフォルトではそれにコンパイルされます。
2. $0 = dyn fmt::Debug 、アイデンティティの強制があります。 これは、 $0: Sized要件と矛盾しています。

コンパイラーは、あいまいさを考慮するときにあまり多くのものを開かないようにします。これは、パフォーマンスの問題とデバッグが難しい問題の両方を引き起こす可能性があるため、かなり愚かな方法で使用する強制を選択します（特に、 T: CoerceUnsized<T>がないため、コンパイラがオプション1を選択すると、非常に簡単に「スタック」する可能性があります）、オプション2を選択することになり、失敗します。 私はそれをもう少し賢くしてオプション1を選ぶという考えを持っていました。

したがって、このPOVからそれを考えると、正しい考えは、次の場合にサイズのない強制をトリガーすることかもしれません。

1. サイズのない強制は自己矛盾がありません（あいまいさが問題ないことを除いて、それが現在のルールになります）。
2. サイズのない強制をトリガーし

$ 0 = dyn fmt :: DebugでID強制を行います。 これは、$ 0：サイズの要件と矛盾しています。

let v: str=!許可する必要があるのに、 let v: str;許可しない理由はほとんどわかりません。 特定の型で変数を宣言することさえできない場合、なぜ（おそらく不可能な）値をそれにバインドできるのでしょうか？

サイズなしの右辺値が出荷されない場合、一貫した方法は、サイズなしの型への強制を許可しないことです。これは、想像上の場合でも、サイズなしの右辺値を（おそらく一時的に）作成するためです。

したがって、私の結論は、 Box::new(!) as Box<Error>問題は、 !タイプではなく、サイズのない右辺値のブロッキングの問題であるということです。 !強制ルールは次のようになります。

let v: T = !書くことができる場合に限り、 let v: Tを書くことができます。

その後、実際の意味は言語で評価されます。 特に、サイズ変更されていない右辺値があると、 Box::new(! as dyn Debug)が、その前は、いいえと言います。

では、前進するために何ができるでしょうか。

サイズなしの強制をトリガーする機能ゲートをコードに追加します。サイズなしの右辺値がオンの場合は、この強制を試してください。それ以外の場合はスキップしてください。 これが唯一の利用可能な強制である場合、エラーメッセージは、同様の場合のように、「特性境界str: std::marker::Sizedが満たされていません」である必要があります。 そう

これは、より大きな関数のパフォーマンスを損なうことなく計算できることを確認する必要があります。

対処されます：単純な機能チェック。

一方、サイズ変更されていない

興味深い。

この

fn main() {
    let _:str = *"";
}

コンパイルしますが

fn main() {
    let v:str = *"";
}

しない。 これは!タイプとは関係ありません。 これについて問題を作成しますか？

最後のものが本当にバグなのかどうかはわかりません。 2番目の例はコンパイルされません。これは、サイズ変更されていない右辺値のサポートがないと、コンパイラーがローカル変数vに割り当てるスタックスペースの量を静的に知りたいが、DSTであるためにできないためです。

最初の例では、 _パターンは、（ローカル変数のバインディングなど）何かに一致するだけでなく、変数をまったく作成しないという点で特別です。 したがって、そのコードはlet除いたfn main() { *""; }と同じです。 参照（DSTでさえ）を逆参照してから結果に対して何もしないことは役に立ちませんが、それは有効であるように思われ、無効であるべきだと私は確信していません。

右。 しかし、それは本当に混乱しています、特に次の

fn main() {
    let _v:str = *"";
}

どちらもコンパイルしません。 _についてのあなたの理論では、これは、未使用のものを単に_ではなく_vと呼ぶことを除いて、同じであるはずです。

私が覚えていることから、 _vとvの唯一の違いは、先頭の下線が未使用の値に関する警告を抑制していることです。

一方、 _具体的には「破棄」を意味し、パターン内の複数の場所（タプルの解凍、引数リストなど）に表示されるようにするために特別に処理されます。名前の衝突に関するエラー。

一方、_は具体的には「破棄」を意味し、名前に関するエラーを発生させることなく、パターン内の複数の場所（タプルの解凍、引数リストなど）に表示できるようにするために特別に処理されます。衝突。

正しい。 あなたが言ったことに加えて、 let _ = foo()はdropがすぐに呼び出されることにつながりますが、 _vはスコープ外になったときにのみドロップされます（ vように） ）。

確かに、これは私が「 _は特別だ」という意味です。

そのため、現在、サイズのないすべての右辺値を拒否することは（機能「サイズのない右辺値」がオンになっていない限り）重大な変更になるように見えますが、効果はほとんどないと思います。

それでも、 !からサイズのない右辺値への強制を禁止する機能ゲートを用意することをお勧めします。 これはlet _:str = return;ようなコードを拒否しますが、コードでそれを使用する人はいないと思います。

!タイプが不安定である限り、強制できる場所とできない場所に重大な変更を加えることができます。

問題は、 https：//github.com/rust-lang/rust/issues/49593を修正するためにDSTに強制せずに安定させた場合、後でサイズのない右辺値を追加したときにそのような強制を復元したいのか、ということです。 https://github.com/rust-lang/rust/issues/49593を再び壊すことなくそうすることができ

私の以前の提案にはこれが含まれています。 ＃49593は、サイズ変更されていない右辺値のブロックの問題になるはずです。

最終的な解決策についての私の個人的な提案は、 Box::new （他のいくつかの重要なメソッドも含まれる場合があります）にサイズのないパラメーターを受け入れさせ、同様の状況であいまいさを許容することです。

FWIW、 _は特別な変数名のようなものではありあり、一致する場所には何もし値ではなく場所で機能します。
変数バインディングに最も近いのはref _xですが、それでも、それによる借用の競合を回避するためにNLLが必要になる可能性があります。 これはところで動作します：

// The type `str` is the type of the place being matched. `x` has type `&str`.
let ref x: str = *"foo";
// Fully equivalent to this:
let x: &str = &*"foo";

@eddyb

あなたは私の主張を理解できませんでした。 私の推測では、Rustには現在、サイズ変更されていない右辺値はコードにまったく表示されません。 ただし、 let _:str = *""に表示されることがわかりました。 そのような価値はすぐに生きることができますが、シンタティックレベルでは生きています。 幽霊のようなもの...

代わりに、あなたの例は技術的に完全に合法であり、それは重要ではありません。 strはサイズ設定されていませんが、 &strはサイズ設定されています。

ただし、let _：str = * ""に表示されることがわかりました。 そのような価値はすぐに生きることができますが、シンタティックレベルでは生きています。 幽霊のようなもの...

&*fooような式にも同様の「ゴースト」があります。 最初にfooを逆参照し、次に結果を移動せずに結果のアドレスを取得します。 したがって、たとえば& { *foo }と同じではありません。

@earthengine @SimonSapinサイズ変更されていない右辺値（「値式」）は存在しません。 左辺値（「場所の式」）のみが実行します。 *"foo"は場所であり、パターンマッチングには値は必要なく、場所のみが必要です。

名称「左辺値」と「右辺値は」、錆で遺物と多少あまりにもCで誤解を招くが、さらに悪化しているので、 letのRHSは、名前にもかかわらず、 『左辺値』（場所式）、です。
（代入式は、Cの名前とルールがRustで意味をなす唯一の場所です）

あなたの例、 let x = *"foo";では、値はxにバインドするために必要です。
同様に、 &*"foo"は場所式を作成し、それを借用します。サイズなしの値を作成する必要はありませんが、 {*"foo"}は常に値式であるため、サイズなしの型は許可されません。

https://github.com/rust-lang/rust/pull/52420で私はそれを打った

let Ok(b): Result<B, !> = ...;
b

動作しなくなりました。 それは意図的なものですか？

AFAIKはい-間違いのないパターンストーリーは複雑で、 !自体とは別の機能ゲートがあります。 https://github.com/rust-lang/rfcs/pull/1872およびhttps://github.com/rust-lang/rust/issues/48950も参照して

@ Ericson2314具体的には、 liballocに追加する必要がある機能はexhaustive_patternsです。

ありがとう！！

内部に関する興味深い会話：

• __問題：__書き込めない
  rust fn make_iter() -> impl Iterator<Item=u32> { unimplemented!() // Error: ! does not implement Iterator }
!は、関連する任意の型に対してIteratorを実装できなかった可能性があるためです。
• __提案：__ <! as Trait>::Assoc型推論変数を生成させましょう。
  
  
  
  • __注：__型システムの拡張は、たとえばfn foo<T:Trait>() -> (T::Assoc, T::Assoc)が同じ型の2つを生成することが保証されるようにするために必要になります。
  
  
• __反例：__ typemapクレートは不健全になります。

あなたがそれをするつもりなら、なぜ治療しませんか！ 推論変数としてそれ自体？

アイテムタイプを明確にするために、 PhandomData !周りにラッパーを作成するだけです。

https://github.com/rust-lang/rust/issues/49593が修正されました。 これが、以前の安定化の復帰の理由でした。 以前の安定化レポートはこちらです。 これをもう一度試してみましょう！

@rfcbotfcpマージ

rfcbotは、同じ問題で複数のFCPをサポートする可能性があると思います。 このラウンドの安定化のために新しい問題を開きましょう。

https://github.com/rust-lang/rust/pull/50121安定化を元に戻すだけでなく、フォールバックセマンティクスも元に戻しました。 これは私たちが再訪したいものですか？

問題の説明の残りのチェックされていないチェックボックスは次のとおりです。

!に対してどのような特性を実装する必要がありますか？ 最初のPR＃35162には、 Ordとその他のいくつかが含まれています。 これはおそらくT-libsの問題であるため、そのタグを問題に追加します。

後でimplを追加できますね。 それともこれはブロッカーですか？

@SimonSapinがhttps://github.com/rust-lang/rust/issues/57012を開きました。 この変更の一環として、 !へのフォールバックが再び有効になることを期待しています（ただし、安定化の問題については説明します）。

相互参照： https ：

どうやら、機能ゲートの後ろに決して入力しないことにはバグ/穴があり、Stableでそれを参照することができます： //github.com/rust-lang/rust/issues/33417#issuecomment -467053097

編集： https ： //github.com/rust-lang/rust/issues/58733に提出

上にリンクされているコード例にタイプの使用を追加します。

trait MyTrait {
    type Output;
}

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

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

fn main() {
    let _a: Void;
}

これはRust1.12.0でコンパイルされます。これは、 ます。 1.11.0では、次のエラーが発生します。

error: the trait bound `fn() -> !: MyTrait` is not satisfied [--explain E0277]
  --> a.rs:12:13
   |>
12 |>     let _a: Void;
   |>             ^^^^
help: the following implementations were found:
help:   <fn() -> T as MyTrait>

error: aborting due to previous error

これの状態はどうですか？

私の知る限り、 https： //github.com/rust-lang/rust/issues/57012#issuecomment -467889706の要約以降、ステータスは大幅に変更されていません。

これの状態はどうですか？

@hosunrise ：現在https://github.com/rust-lang/rust/issues/67225でブロックされてい

私はここから離れているかもしれませんが、lintディスカッション（https://github.com/rust-lang/rust/issues/66173）で言及​​されている特定の問題は、すべての列挙型に!ブランチがある場合、両方とも解決できるようです。型システム？

https://github.com/rust-lang/rust/issues/67225のOPに記載されている問題には適用されないことに注意して

私はここから離れているかもしれませんが、lintの議論（＃66173）が言及している特定の問題は、すべての列挙型に型システムに!ブランチがある場合、両方とも解決できるように見えますか？

実際には、発生する可能性のないバリアントが無数にあるため、すべての列挙型が脅威にさらされる可能性があります。したがって、それらすべてに言及する価値はありません。