RFCの議論でそれを見逃したかもしれませんが、ユニオンバリアントのデストラクタは決して実行されないと考えるのは正しいですか？ この例では、 Box::new(1)のデストラクタが実行されますか？

union Foo {
    f: i32,
    g: Box<i32>,
}

let mut f = Foo { g: Box::new(1) };
f.g = Box::new(2);

@sfackler私の現在の理解では、 f.g = Box::new(2)デストラクタを実行しますが、 f = Foo { g: Box::new(2) }は実行しません。 つまり、 Box<i32>左辺値に割り当てると、いつものようにドロップが発生しますが、 Foo左辺値に割り当てるとドロップは発生しません。

したがって、バリアントへの割り当ては、フィールドが以前に「有効」であったというアサーションのようなものですか？

@sfackler Dropタイプの場合、ええ、それは私の理解です。 以前は有効でなかった場合は、 Fooコンストラクターフォームまたはptr::writeを使用する必要があります。 簡単なgrepからは、RFCがこの詳細について明示しているようには見えませんが。 Drop左辺値に書き込むと、デストラクタ呼び出しが発生するという一般的なルールのインスタンス化と見なされます。

ドロップバリアントとの＆mutユニオンは糸くずである必要がありますか？

2016年4月8日金曜日、ScottOlsonnotifications @ github.comは次のように書いています。

@sfackler https://github.com/sfacklerドロップタイプの場合、ええ、それは私のです
理解。 以前は有効でなかった場合は、Fooを使用する必要があります
コンストラクターフォームまたはptr :: write。 簡単なgrepからは、
ただし、RFCはこの詳細について明示しています。

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

2016年4月8日午前3時36分22秒PM PDTで、スコットオルソンの[email protected]は書きました：

@sfackler Dropタイプの場合、ええ、それは私の理解です。 もし彼らが
以前は有効ではなかったため、 Fooコンストラクタフォームを使用する必要があります。
ptr::write 。 簡単なgrepからは、RFCがそうであるようには見えません
ただし、この詳細については明示的です。

私はそのケースを明確にカバーすべきだった。 どちらの動作も防御可能だと思いますが、暗黙的にフィールドをドロップしないことはそれほど驚くことではないと思います。 RFCは、Dropを実装する型のユニオンフィールドにlintをすでに推奨しています。 フィールドへの割り当ては、フィールドが以前に有効であったことを意味するとは思いません。

ええ、そのアプローチは私にとっても少し危険が少ないようです。

ユニオンフィールドに割り当てるときにドロップしないと、 f.g = Box::new(2)動作がlet p = &mut f.g; *p = Box::new(2)は異なります。後者の場合、ドロップしないようにすることができないためです。 私のアプローチはそれほど驚くべきことではないと思います。

これも新しい問題ではありません。 unsafeプログラマーは、 fooが初期化されておらず、 Dropの場合、 foo = barがUBである他の状況にすでに対処する必要があります。

個人的には、ユニオンでドロップタイプを使用する予定はまったくありません。 したがって、私は、そうすることのセマンティクスに関して類似の安全でないコードを扱った人々に完全に任せます。

また、ユニオンでDropタイプを使用するつもりはないので、一貫している限り、どちらの方法でも問題ありません。

ユニオンへの可変参照を使用するつもりはありません。おそらく
Intoで「奇妙なタグが付けられた」ものだけ

2016年4月8日（金曜日）に、ピーターAtashianの[email protected]は書きました：

また、ユニオンでドロップタイプを使用するつもりはないので、どちらの方法でも使用しません
それが一貫している限り、私にとって重要です。

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

これは未解決の質問として提起するのに良い問題のようです。 どちらのアプローチを好むかはまだわかりません。

@nikomatsakis Dropを持つタイプのユニオンフィールドに割り当てて、そのフィールドの以前の有効性を要求するのは厄介だと思うのと同じ@tsionはほとんど避けられないようです。 これは、Dropを含む型をユニオンに配置するためのlintを意図的に無効にするコードに関連する落とし穴かもしれないと思います。 （そして、それについての簡単な説明は、その糸くずの説明文にあるはずです。）

そして、 unsafeプログラマーは、安全なコードを書くためにa = b drop_in_place(&mut a); ptr::write(&mut a, b)を意味することをすでに一般的に知っている必要があることを繰り返し述べたいと思います。 ユニオンフィールドを削除しないことは、学ぶべき例外であり、1つ少なくなることはありません。

（注： aが、 let a; a = b;ように、すでに初期化されていないことが_静的に_わかっている場合、ドロップは発生しません。）

しかし、これはかなり非自明な詳細であるため、組合のDropバリアントに対して、人々が#[allow(..)]なければならないというデフォルトの警告があることをサポートします。

@tsionこれは当てはまりませんa = bと、おそらく唯一の、時には真のためのa.x = bが、それは確かに当てはまります*a = b 。 この不確実性が私を躊躇させた理由です。 たとえば、これは次のようにコンパイルされます。

fn main() {
  let mut x: (i32, i32);
  x.0 = 2;
  x.1 = 3;
}

（後でxを印刷しようとすると失敗しますが、バグだと思います）

@nikomatsakisその例は私にとって新しいものです。 私の以前の経験を考えると、その例がコンパイルされるのはバグだと思っていたと思います。

しかし、その例の関連性がわかるかどうかはわかりません。 なぜ私は真実ではないと述べたものですa = bとだけ時々のためにa.x = b ？

たとえば、 x.0デストラクタのある型がある場合、そのデストラクタは必ず呼び出されます。

fn main() {
    let mut x: (Box<i32>, i32);
    x.0 = Box::new(2); // x.0 statically know to be uninit, destructor not called
    x.0 = Box::new(3); // x.0 destructor is called before writing new value
}

たぶん、その種の書き込みに反対するだけですか？

私のポイントは、 =がデストラクタを_常に_実行しないということだけです。 それ
ターゲットがであることがわかっているかどうかについての知識を使用します
初期化されました。

2016年4月12日火曜日04:10:39 PM -0700、スコットオルソンは次のように書いています。

@nikomatsakisその例は私にとって新しいものです。 私の以前の経験を考えると、その例がコンパイルされるのはバグだと思っていたと思います。

しかし、その例の関連性がわかるかどうかはわかりません。 私が言ったことはa = bには当てはまらず、「ax = b」にはたまにしか当てはまらないのはなぜですか？

たとえば、 x.0デストラクタのある型がある場合、そのデストラクタは必ず呼び出されます。

fn main() {
    let mut x: (Box<i32>, i32);
    x.0 = Box::new(2); // x.0 statically know to be uninit, destructor not called
    x.0 = Box::new(3); // x.0 destructor is called
}

@nikomatsakis

ドロップフラグが設定されている場合、デストラクタを実行します。

しかし、とにかくそのような書き込みは混乱を招くと思うので、なぜそれを禁止しないのですか？ いつでも*(&mut u.var) = valます。

私のポイントは、 =がデストラクタを_常に_実行しないということだけです。 ターゲットが初期化されていることがわかっているかどうかについての知識を使用します。

@nikomatsakis私はすでにそれについて言及しました：

（注：let a; a = b;。のように、aがすでに初期化されていないことが静的にわかっている場合、ドロップは発生しません。）

しかし、私はドロップフラグの動的チェックを考慮していなかったので、これは私が考えていたよりも間違いなく複雑です。

@tsion

ドロップフラグは半動的です-ゼロ化ドロップがなくなった後、それらはcodegenの一部です。 私たちは、それが良いよりも混乱を招くので、そのような書き込みを禁止すると言います。

Dropタイプもユニオンで許可する必要がありますか？ 私が物事を正しく理解している場合、Rustにユニオンがある主な理由は、ユニオンを持つCコードとインターフェイスすることであり、Cにはデストラクタすらありません。 他のすべての目的でenum 、Rustコードで

ユニオンを使用して、ドロップを禁止するNoDropタイプを実装するための有効なユースケースがあります。

また、 drop_in_placeなどを介して手動でそのようなコードを呼び出すこともできます。

前のオプションタイプが定義されていないため、書き込み中にフィールド値を削除することは間違いなく間違っています。

フィールドセッターを禁止することは可能ですか？しかし、完全なユニオンの交換が必要ですか？ この場合、ユニオンがDropを実装すると、期待どおりに置き換えられた値に対して完全なユニオンドロップが呼び出されます。

フィールドセッターを禁止することは意味がないと思います。 ユニオンのほとんどの使用はそれらを使用しても問題がないはずであり、Drop実装のないフィールドはおそらく一般的なケースのままです。 ドロップを実装するフィールドを持つユニオンは、デフォルトで警告を生成し、このケースに誤ってヒットする可能性をさらに低くします。

議論のために、ユニオンのフィールドへの可変参照を公開し、任意の（おそらくDrop ）タイプをフィールドに配置するつもりです。 基本的に、ユニオンを使用してカスタムのスペース効率の高い列挙型を作成したいと思います。 例えば、

union SlotInner<V> {
    next_empty: usize, /* index of next empty slot */
    value: V,
}

struct Slot<V> {
    inner: SlotInner<V>,
    version: u64 /* even version -> is_empty */
}

@nikomatsakisここで未解決として現在リストされている質問に対する具体的な回答を提案したいと思います。

不必要に複雑なセマンティクスを回避するには、ユニオンフィールドへの割り当ては、構造体フィールドへの割り当てと同じように機能する必要があります。つまり、古いコンテンツを削除します。 代わりに組合全体に割り当てることで、それを知っていればこれを回避するのは簡単です。 これはまだ少し意外な動作ですが、 Dropを実装するユニオンフィールドがあると警告が生成され、その警告のテキストでこれを警告として明示的に言及できます。

この動作を文書化するためにRFC1444を修正するRFCプルリクエストを提供することは意味がありますか？

@joshtriplett @nikomatsakisは休暇で不在なので、私は答えます：このような質問を解決するための修正RFCを提出するのは素晴らしいフォームだと思います。 必要に応じて、このようなRFCPRを迅速に追跡することがよくあります。

@aturonありがとう。 この問題を解決するために、これらの説明を含む新しいRFC PRhttps ：//github.com/rust-lang/rfcs/issues/1663をRFC1444に提出しました。

_{（ @aturonは、その未解決の質問を今すぐチェックオフできます。）}

https://github.com/petrochenkov/rust/tree/unionにいくつかの予備的な実装があり

ステータス：実装済み（モジュロバグ）、PR送信済み（https://github.com/rust-lang/rust/pull/36016）。

@petrochenkov素晴らしい！ これまでのところ素晴らしく見えます。

ムーブチェッカーでCopyフィールドを持つユニオンを処理する方法がよくわかりません。
uがunion U { a: A, b: B }初期化された値であり、フィールドの1つから移動するとします。

1） A: !Copy, B: !Copy, move_out_of(u.a)
これは簡単で、 u.bも初期化されていない状態になります。
サニティチェック： union U { a: T, b: T }は、 struct S { a: T } +フィールドエイリアスとまったく同じように動作する必要があります。

2） A: Copy, B: !Copy, move_out_of(u.a)
move_out_of(u.a)は単なるmemcpyあり、 u.bはまったく変更されないため、おそらくu.bはまだ初期化する必要があります。

2） A: !Copy, B: Copy, move_out_of(u.a)
これは最も奇妙なケースです。 おそらくu.bも、 Copyにもかかわらず、初期化されていない状態にする必要があります。 Copy値は初期化されていない可能性がありますが（たとえば、 let a: u8; ）、状態を初期化されたものから初期化されていないものに変更することは、新しいことです。

@ retep998
私はこれがFFIのニーズとは完全に無関係であることを知っています:)
幸いなことに、これはブロッカーではありません。より単純な動作を実装し、今週末にPRを送信します。

@petrochenkov私の本能は、組合は本質的に「ビットバケット」であるということです。 データが初期化されているかどうか、およびそのTrueTypeが何であるかを追跡するのはユーザーの責任です。 これは、生のポインタの指示対象と非常によく似ています。

これが、データを削除できない理由であり、フィールドへのアクセスが安全でない理由でもあります（たとえば、バリアントが1つしかない場合でも）。

これらの規則により、コピーが実装されている場合、組合はCopyを実装することを期待します。 ただし、構造体/列挙型とは異なり、内部のサニティチェックはありません。必要に応じて、いつでも共用体型のコピーを実装できます。

明確にするためにいくつかの例を挙げましょう：

union Foo { ... } // contents don't matter

Copyが実装されていないため、この結合はアフィンです。

union Bar { x: Rc<String> }
impl Copy for Bar { }
impl Clone for Bar { fn clone(&self) -> Self { *self } }

Copyが実装されているため、この共用体タイプBarはコピーです。

Barが構造体である場合、フィールドxのタイプが原因で、 Copyを実装するとエラーになることに注意してください。

ええと、私は実際にあなたの質問に答えていないと思います、今私はそれを読み直しました。 =）

さて、私はあなたの質問にまったく答えていなかったことに気づきました。 では、もう一度試してみましょう。 「ビットバケット」の原則に従って、私は、私たちが自由に組合から脱退できることを_まだ_期待しています。 しかしもちろん、別のオプションは、 *mut Tを扱うように扱うことであり、退去するにはptr::readを使用する必要があります。

編集：なぜそのような動きを禁止するのか、私は実際には完全にはわかりません。 移動ドロップを使用する必要があった可能性があります。または、間違いを犯しやすく、「移動」をより明確にする方がよいと思われるからかもしれません。 ここで歴史を思い出すのに苦労しています。

@nikomatsakis

私の本能は、組合は本質的に「ビットバケット」であるということです。

それどころか、ハ、私は、そのような危険な構成に対して、組合の内容についてできるだけ多くの保証を与えたいと思います。

解釈は、ユニオンは判別式がわからない列挙型であるということです。つまり、いつでもユニオンのバリアントの少なくとも1つが有効な値を持つことを保証できます（安全でないコードが含まれている場合を除く）。

現在の実装のすべての借用/移動ルールはこの保証をサポートしますが、同時にこれは最も保守的な解釈であり、「安全な」方法のいずれかを実行できます（たとえば、同じタイプのフィールドを持つユニオンへの安全なアクセスを許可します。これは次のようになります。便利な）または将来、Rustユニオンの経験がさらに集まる「ビットバケット」の方法。

実際には、 https： //github.com/rust-lang/rust/pull/36016#issuecomment -242810887で説明されているように、さらに保守的にしたいと思い

@petrochenkov

解釈は、ユニオンは判別式がわからない列挙型であるということです。つまり、いつでもユニオンのバリアントの少なくとも1つが有効な値を持つことを保証できます（安全でないコードが含まれている場合を除く）。

ユニオンを使用する場合、フィールドへのすべてのアクセスが安全ではないため、安全でないコードが常に含まれることに注意してください。

私の考え方は似ていると思います。 基本的に、ユニオンは列挙型のようなものですが、同時に複数のバリアントに含めることができます。 有効なバリアントのセットは、コンパイラにはどの時点でも認識されていませんが、セットが空である（つまり、列挙型が初期化されていない）ことがわかる場合があります。

したがって、 some_union.field使用は、基本的に、有効なバリアントのセットに現在field含まれているという暗黙の（そして安全ではない）アサーションであると考えています。 これは、ボローチェッカー統合の仕組みと互換性があるようです。 フィールドxを借用してからyを使用しようとすると、基本的にデータがxとyと言っているため、エラーが発生します。 （そしてそれは借りられます）。 （対照的に、通常の列挙型では、一度に複数のバリアントに生息することはできません。これは、借用ルールがどのように実行されるかで確認できます）。

とにかく、要点は、ユニオンの1つのフィールドから「移動」するとき、当面の問題は、値を他のバリアントとして解釈することがもはや有効ではないことを意味すると推測できるかどうかです。 とはいえ、どちらの方法でも議論するのはそれほど難しいことではないと思います。 これはグレーゾーンだと思います。

保守的であることの危険性は、そうでなければ意味があり有効である安全でないコードを除外する可能性があることです。 しかし、私はきつく始めて、後で緩めるかどうかを決めることで大丈夫です。

ユニオンにCopyを実装するために必要な条件について話し合う必要があります。また、安定化の前に対処して文書化するために、上記の灰色の領域の完全なリストがあることを確認する必要があります。

基本的に、ユニオンは列挙型のようなものですが、同時に複数のバリアントに含めることができます。

「複数のバリアント」の解釈に対する1つの議論は、ユニオンが定数式でどのように動作するかです。これらのユニオンの場合、常に単一のアクティブなバリアントを知っており、コンパイル時の変換が一般的に悪いため、非アクティブなバリアントにアクセスできません（コンパイラをある種の部分的なターゲットエミュレータに変えるため）。
私の解釈では、実行時に非アクティブなバリアントはまだ非アクティブですが、ユニオンのアクティブなバリアント（より制限的な定義）またはユニオンのフラグメント割り当て履歴（より曖昧ですが、より便利）とレイアウト互換性がある場合にアクセスできます。

これらの灰色の領域の完全なリストがあることを確認する必要があります

それほど遠くない将来に、ユニオンRFCを修正するつもりです！ 「列挙型」の解釈は、かなり楽しい結果をもたらします。

コンパイル時の変換は一般的に悪いです（コンパイラをある種の部分的なターゲットエミュレータに変えようとしているのでない限り）

@petrochenkovこれは私のMiriプロジェクトの目標の1つです。 ミリはすでに核変換やさまざまな生のポインターシェナニガンを行うことができます。 Miriにユニオンを処理させるのは少しの作業です（生のメモリ処理側では何も新しいことはありません）。

そして、 @ eddybは、rustc定数評価をMiriのバージョンに置き換えることを推進しています。

@petrochenkov

「複数のバリアント」の解釈に対する1つの議論は、組合が定数式でどのように動作するかです。

定数での共用体の使用を最適にサポートする方法は興味深い質問ですが、定数式を実行時の動作のサブセットに制限することに問題はありません（とにかく、これは常に行っていることです）。 つまり、コンパイル時に特定のトランスミュートを完全にサポートできない可能性があるからといって、実行時に違法であるとは限りません。

私の解釈では、実行時に非アクティブなバリアントはまだ非アクティブですが、ユニオンのアクティブなバリアントとレイアウト互換性がある場合はアクセスできます

うーん、私はこれが、ユニオンがそれらすべてのバリアントに同時に属していると言うこととどのように違うのかを考えようとしています。 まだ違いはわかりません。 :)

この解釈は、一般的に動きと奇妙な相互作用を持っているように感じます。 たとえば、データが「実際に」Xであり、それをYとして解釈したが、Yがアフィンである場合、それはまだXですか？

とにかく、どの分野の動きでも組合全体を消費することは、これらの解釈のいずれかと一致していると見なすことができるのは問題ないと思います。 たとえば、「バリアントのセット」アプローチでは、値を移動すると既存のすべてのバリアントが非初期化されるという考え方です（もちろん、使用したバリアントは有効なセットの1つである必要があります）。 あなたのバージョンでは、それはそのバリアントに「変換」するように見えます（そしてオリジナルを消費します）。

それほど遠くない将来に、ユニオンRFCを修正するつもりです！ 「列挙型」の解釈は、かなり楽しい結果をもたらします。

そんな自信！ あなたは試してみるつもりです;）

あなたが考えている具体的な変更について、もう少し詳しく説明しますか？

あなたが考えている具体的な変更について、もう少し詳しく説明しますか？

実装のより詳細な説明（つまり、より良いドキュメント）、いくつかの小さな拡張（空のユニオンとユニオンパターンの..など）、ユニオン進化の2つの主要な（矛盾する）代替案-より安全で制限の少ない「スクラッチスペース」解釈と、より安全でより制限的な「判別式が不明な列挙型」解釈-および移動/初期化チェッカー、 Copy impls、 unsafe tyのフィールドアクセスなどへの影響。

非アクティブなユニオンフィールドにアクセスするのがUBである場合を定義することも役立ちます。

union U { a: u8, b: () }
let u = U { b: () };
let a = u.a; // most probably an UB, equivalent to reading from `mem::uninitialized()`

しかし、これは無限にトリッキーな領域です。

おそらく、クロスフィールドセマンティクスは基本的にポインタキャストですよね？
_（_（）as * u8）

木曜日に、2016年9月1日、ヴァディムPetrochenkov [email protected]
書きました：

非アクティブなユニオンフィールドにアクセスするときに定義することも役立ちます
UB、例えば

ユニオンU {a：u8、b :(）}
u = U {b :(）};
a = uaとします。 //おそらくUB、 mem::uninitialized()からの読み取りに相当

しかし、これは無限にトリッキーな領域です。

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

フィールドアクセスは常に安全ではありませんか？

木曜日に、2016年9月1日、ヴァディムPetrochenkov [email protected]
書きました：

あなたが考えている具体的な変更について、もう少し詳しく説明しますか？

実装のより詳細な説明（つまり、より良い
ドキュメント）、いくつかの小さな拡張機能（空のユニオンや..インユニオンなど）
パターン）、ユニオン進化の2つの主要な（矛盾する）代替案-詳細
安全ではなく、制限の少ない「スクラッチスペース」の解釈とより安全
より制限的な「判別式が不明な列挙型」の解釈-および
移動/初期化チェッカー、コピーimpls、安全性に対するそれらの結果
フィールドアクセスなどの

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

フィールドアクセスは常に安全ではありませんか？

時々安全にすることができます、例えば

• 自明に破壊可能なユニオンフィールドへの割り当ては安全です。
• union U { f1: T, f2: T, ..., fN: T }フィールドへのアクセス（つまり、すべてのフィールドが同じタイプ）は、「判別式が不明な列挙型」の解釈で安全です。

ユーザーの観点からは、これに特別な条件を適用しない方がよいようです。 常に安全ではないと言ってください。

現在、gitの最新のrustcでユニオンのサポートをテストしています。 私が試したものはすべて完璧に機能します。

デッドフィールドチェッカーで興味深いケースに遭遇しました。 次のコードを試してください。

#![feature(untagged_unions)]

union U {
    i: i32,
    f: f32,
}

fn main() {
    println!("{}", std::mem::size_of::<U>());
    let u = U { f: 1.0 };
    println!("{:#x}", unsafe { u.i });
}

このエラーが発生します：

warning: struct field is never used: `f`, #[warn(dead_code)] on by default

dead_codeチェッカーが初期化に気づかなかったようです。

（私はすでに「structfield」の使用についてPR＃36252を提出し、それを単に「field」に変更しました。）

ユニオンには現在、動的なサイズのフィールドを含めることはできませんが、RFCはこの動作を次のいずれかの方法で指定していません。

#![feature(untagged_unions)]

union Foo<T: ?Sized> {
  value: T,
}

出力：

error[E0277]: the trait bound `T: std::marker::Sized` is not satisfied
 --> <anon>:4:5
  |
4 |     value: T,
  |     ^^^^^^^^ trait `T: std::marker::Sized` not satisfied
  |
  = help: consider adding a `where T: std::marker::Sized` bound
  = note: only the last field of a struct or enum variant may have a dynamically sized type

Contextualキーワードは、モジュール/クレートルートコンテキストの外部では機能しません。

fn main() {
    // all work
    struct Peach {}
    enum Pineapple {}
    trait Mango {}
    impl Mango for () {}
    type Strawberry = ();
    fn woah() {}
    mod even_modules {
        union WithUnions {}
    }
    use std;

    // does not work
    union Banana {}
}

かなり厄介な一貫性の疣贅のようです。

@nagisa
誤って古いバージョンのrustcを使用していますか？
playpenであなたの例を確認したところ、動作します（モジュロ「空のユニオン」エラー）。
この特定の状況をチェックする実行パステストもあります-https：//github.com/rust-lang/rust/blob/master/src/test/run-pass/union/union-backcomp.rs。

@petrochenkovああ、私はplay.rloを使用しましたが、 stableか何かに戻ったようです。 それなら、私を気にしないでください。

組合は最終的に、この提案からの危険な分野の邪悪な双子である_安全な分野_を支援する必要があると思います。
cc https://github.com/rust-lang/rfcs/issues/381#issuecomment -246703410

さまざまな基準に基づいて「安全な組合」を宣言する方法があることは理にかなっていると思います。

たとえば、すべて同じサイズのコピー非ドロップフィールドのみを含むユニオンは安全のようです。 フィールドにどのようにアクセスしても、予期しないデータが表示される可能性がありますが、メモリの安全性の問題や未定義の動作は発生しません。

@joshtriplettまた、初期化されていないデータを読み取ることができるタイプに「穴」がないことを確認する必要があります。 私が言いたいのは、「初期化されていないデータは、予測できないランダムデータまたはSSH秘密鍵のいずれか悪い方です。」

&Tコピーと非ドロップではありませんか？ それをusizeとの「安全な」結合に入れると、不正な参照ジェネレーターができあがります。 したがって、ルールはそれよりも少し厳格にする必要があります。

たとえば、すべて同じサイズのコピー非ドロップフィールドのみを含むユニオンは安全のようです。 フィールドにどのようにアクセスしても、予期しないデータが表示される可能性がありますが、メモリの安全性の問題や未定義の動作は発生しません。

これは単なる例であり、深刻な提案ではないことを理解していますが、これがいかに難しいかを示すいくつかの例を次に示します。

• u8とboolサイズは同じですが、ほとんどのu8値はboolに対して無効であり、これを無視するとUBがトリガーされます
• &Tと&Uは同じサイズで、すべてのTとUに対してCopy + !Dropです（両方またはどちらもSizedない限り）
• uN / iNとfN間の変換は、現在、安全でないコードでのみ可能です。 そのような核変換は常に安全であると私は信じていますが、これは安全な言語を拡大するので、物議を醸すかもしれません。
• プライバシーの侵害（たとえば、 struct Foo(Bar);とBar駄洒落）は、プライバシーが安全に関連する不変条件を維持するために使用される可能性があるため、大したことではありません。

@Amanieuそれを書いているとき、内部にパディングがないことについてのメモを含める

@cuviperポインタがゼロのようなもののように、「プレーンな古いデータ」を定義しようとしていました。 そうです、定義は参照を除外する必要があります。 許可されたタイプのセットとそれらのタイプの組み合わせをホワイトリストに登録する方がおそらく簡単です。

@rkruppe

u8とboolのサイズは同じですが、ほとんどのu8値はboolには無効であり、これを無視するとUBがトリガーされます。

いい視点ね; 同じ問題が列挙型にも当てはまります。

＆Tと＆Uのサイズは同じで、すべてのTとUに対してコピー+！ドロップです（両方またはどちらもサイズ設定されていない場合）

私はそれを忘れていました。

uN / iNとfNの間の核変換は、現在、安全でないコードでのみ可能です。 そのような核変換は常に安全であると私は信じていますが、これは安全な言語を拡大するので、物議を醸すかもしれません。

両方の点で合意しました。 これは許容できるようです。

プライバシーの侵害（たとえば、struct Foo（Bar）;とBarの間のしゃれ）は、安全に関連する不変条件を維持するためにプライバシーが使用される可能性があるため、大したことではありません。

タイプの内部がわからない場合、内部が要件を満たしているかどうかを知ることはできません（内部パディングがないなど）。 したがって、すべてのコンポーネントが再帰的にプレーンな古いデータであり、それを検証するのに十分な可視性があることを要求することで、これを除外できます。

uN / iNとfNの間の核変換は、現在、安全でないコードでのみ可能です。 そのような核変換は常に安全であると私は信じていますが、これは安全な言語を拡大するので、物議を醸すかもしれません。

浮動小数点数には、UBをもたらすトラップ表現であるシグナリングNaNがあります。

@ retep998 Rustは、浮動小数点トラップの無効化をサポートしていないプラットフォームで実行されますか？ （これでUBの問題は変わりませんが、理論的にはその問題を解決することができます。）

@petrochenkov

解釈は、ユニオンは判別式がわからない列挙型であるということです。つまり、ユニオンのバリアントの少なくとも1つが有効な値を持っていることをいつでも保証できます。

私はこの解釈にたどり着いたと思います-まあ、これは_正確に_ではありません。 私はいつものように、あなたが保管する時点で決定されるいくつかの合法的な変種があるので、それを今でも考えています。 値をユニオンに格納することは、それを「量子状態」にするのと少し似ていると思います。これで、多くの法的な解釈の1つに変換される可能性があります。 しかし、私は、これらのバリアントの1つから移動するときに、それをそれらの1つだけに「強制」し、その価値を消費したことに同意します。 したがって、列挙型を再度使用することはできません（そのタイプがCopyない場合）。 だから👍、基本的に。

#[repr(C)]に関する質問： @pnkfelixが最近私に指摘したように、現在の仕様では、共用体が#[repr(C)]でない場合、フィールドx格納して読み取ることは違法であると述べています。フィールドyます。 おそらくこれは、すべてのフィールドを同じオフセットで開始する必要がないためです。

これにはいくつかのユーティリティがあります。たとえば、サニタイザーは、通常の列挙型（または構造体...？）のようにユニオンを格納し、入力したものと同じバリアントを使用していることを確認することで、ユニオンを実装できます。

_しかし_それは一種のフットガンのように見えます、そしてまたそれらのreprの1つは、あまりにも多くの人々が野生でそれに依存するので、実際には_実際に_変更することが決してできないことを保証します。

考え？

@nikomatsakis

解釈は、ユニオンは判別式がわからない列挙型であるということです。つまり、ユニオンのバリアントの少なくとも1つが有効な値を持っていることをいつでも保証できます。

最悪の部分はバリアント/フィールドフラグメントであり、ユニオンが直接アクセスできます。
このコードを検討してください：

union U {
    a: (u8, bool),
    b: (bool, u8),
}
fn main() {
    unsafe {
        let mut u = U { a: (2, false) };
        u.b.1 = 2; // turns union's memory into (2, 2)
    }
}

すべてのフィールドはCopyであり、所有権は関係なく、移動チェッカーは問題ありませんが、非アクティブなフィールドbへの部分的な割り当てにより、ユニオンは0有効なバリアントを持つ状態になります。 どう対処すればいいのかまだ考えていません。 そのような割り当てをUBにしますか？ 解釈を変更しますか？ 他に何かありますか？

@petrochenkov

そのような割り当てをUBにしますか？

はい、これは私の仮定です。 aで割り当てた場合、バリアントbは有効なバリアントのセットに含まれていなかったため、後でu.b.1 （読み取りまたは割り当て）は無効です。

＃[repr（C）]に関する質問： @pnkfelixが最近私に指摘したように、現在の仕様では、共用体が＃[repr（C）]でない場合、フィールドxで保存してフィールドyで読み取ることは違法であると述べています。 。 おそらくこれは、すべてのフィールドを同じオフセットで開始する必要がないためです。

ここでの適切な表現は、1）以前に作成されたフィールド/フィールドフラグメントと「レイアウト互換」ではない（これはあいまいです）フィールドからの読み取りはUBです2） #[repr(C)]ユニオンの場合、ユーザーはレイアウトが何であるかを知っています（ABIドキュメントから）UBと非UBを区別できるようにする3） #[repr(Rust)]ユニオンレイアウトは指定されていないため、ユーザーはUBとは何かを言うことはできませんが、WE（rustc / libstd + theirテスト）はこの神聖な知識を持っているので、小麦をもみ殻から分離し、非UB方式で#[repr(Rust)]を使用できます。

4）サイズ/ストライドとフィールドの並べ替えの質問が決まったら、構造体と共用体のレイアウトを石で設定して指定することを期待します。これにより、ユーザーはレイアウトも理解し、 #[repr(Rust)]共用体を使用できるようになります。 #[repr(C)]と同じくらい自由に、問題はなくなります。

@nikomatsakisユニオンRFCの議論で、人々は、ユニオンを使用してコンパクトなデータ構造を構築するネイティブのRustコードが必要だと述べました。

#[repr(C)]を使用している人を止めるものはありますか？ そうでない場合は、 #[repr(Rust)]に何らかの保証を提供する必要はないと思います。「ここでドラゴンになってください」のままにしてください。 おそらく、 #[repr(C)]ではないユニオンに対してデフォルトで警告されるリントを用意するのが最善でしょう。

@ retep998 repr(Rust)が特定のレイアウトやオーバーラップを保証しないことは私には合理的だと思います。 repr(Rust)は、実際には、ユニオンのメモリ使用量（「最大のメンバー以下」）に関する人々の仮定を破ってはならないことをお勧めします。

Rustは、浮動小数点トラップの無効化をサポートしていないプラットフォームで実行されますか？

それは実際に尋ねるのに有効な質問ではありません。 まず第一に、オプティマイザー自体がトラップ表現のUB性に依存し、予期しない方法でプログラムを書き直す可能性があります。 さらに、RustはFP環境の変更も実際にはサポートしていません。

しかし、それは一種のフットガンのように思えます。また、野生ではあまりにも多くの人々がそれに依存するため、実際には決して変更できないことを保証するものの1つです。

考え？

列挙型が他のフィールドで記述されていることが証明されているときに、フィールドから読み取りが行われた場合にプログラムフローを検査し、ユーザーに苦情を投げかける糸くずなどを追加すると、これに役立ちます¹。 MIRベースの糸くずはそれを簡単に処理します。 CFGがユニオンフィールドロードの合法性について結論を出すことを許可せず、ユーザーがミスを犯した場合、未定義の動作は、Rustrepr自体IMOを指定せずに指定できる最善の方法です。

¹：人々が何らかの理由で貧乏人の変身として組合を使い始めた場合に特に効果的です。

実際には、ユニオンのメモリ使用量に関する人々の想定を破るべきではありません（「最大のメンバー以下」）。

同意しません。 たとえば、一部のアーキテクチャでは、 repr(Rust)ものをマシンワードのサイズに拡張することは非常に理にかなっています。

安定化の前に検討する必要があるかもしれない1つの問題は、 https：//github.com/rust-lang/rust/issues/37479です。 最新バージョンのLLDBでは、デバッグユニオンが機能しない可能性があります:(

@alexcrichton GDBで動作しますか？

私の知る限り、そうです。 Linuxボットはテストを問題なく実行しているようです。

つまり、Rustがすべての適切なデバッグ情報を提供し、LLDBにはバグがあります。 複数のデバッガーの1つにバグがあり、別のデバッガーには存在しないため、これを安定させることができないと思います。 LLDBを修正する必要があります。

この機能を1.17サイクル（3月16日のベータ版）でFCPに組み込むことができるかどうかを確認するのはすばらしいことです。 誰かが未解決の質問と機能の現在の状況の要約を提供して、コンセンサスに達し、すべてを解決できるかどうかを確認できますか？

@withoutboats
私の計画は

• 次のリリース（2月3日）を待ちます。
• Copyフィールドを持つユニオンの安定化を提案します。 これはすべてのFFIのニーズをカバーします-FFIライブラリは安定版でユニオンを使用できるようになります。 「POD」ユニオンはC / C ++で何十年も使用されており、よく理解されています（モジュロタイプベースのエイリアシングですが、Rustにはありません）。既知のブロッカーもありません。
• 2月3日まで「Unions1.2」RFCを作成します。これは、組合の現在の実装について説明し、将来の方向性を概説します。 Copyフィールドを持つ組合の将来は、このRFCを議論する過程で決定されます。

標準ライブラリからManuallyDropやNoDropようなものを公開する場合、ユニオンを安定させる必要はないことに注意してください。

ステータスの更新（2月4日）：RFCを作成していますが、通常どおり、各文の後にライターズブロックがあるため、今週末ではなく、次の週末（2月11〜12日）に終了する可能性があります。 （2月4-5日）。
ステータスの更新（2月11日）：テキストは95％準備ができています。明日送信します。

@petrochenkovは、非常に合理的な行動

@petrochenkovそれは私には合理的に聞こえます。 また、あなたの組合1.2の提案を検討し、いくつかのコメントを提供しました。 全体的に、それは私には良さそうです。

@joshtriplett @ rust-lang / langの会議でチェックリストを最新の状態に保つことについて話し合ったときに、実際には、これらの各ポイントについて、肯定的な決定を下すことを望んでいると思っていました。 （つまり、理想的には@rfcbotを使用します）。 これはおそらく明確な問題（またはRFCの修正）を示唆しているでしょう。 時間の経過とともにこれを行うことはできましたが、それまでは、未解決の質問に対する回答を明確に「解決」したとは感じていません。 これらの方針に沿って、関連する会話を抽出して修正RFCに要約したり、ここからリンクできる問題を要約したりすることは、全員が同じページにいることを確認するための優れたステップのように思えます。興味のある人なら誰でもできることです。もちろん、@ rust-lang / langのメンバーや羊飼いだけではありません。

そこで、「Unions1.2」RFC（ https://github.com/rust-lang/rfcs/pull/1897）を提出しました

ここで、ユニオンの保守的なサブセットの安定化を提案したいと思います。ユニオンのすべてのフィールドはCopyであり、フィールドの数はゼロ以外であり、ユニオンはDrop実装しない必要があります。 。
（ただし、最後の要件が実行可能かどうかはわかりません。ユニオンを構造体にラップし、その構造体にDropを実装することで簡単に回避できる可能性があるためです。）
このようなユニオンは、この言語機能の主要な利用者であると思われるFFIライブラリのすべてのニーズをカバーします。

「Unions1.2」RFCのテキストは、型のパンニングが許可されていることを明示的に確認していることを除いて、FFIスタイルのユニオンについて何も新しいことを伝えていません。
編集：「Unions1.2」RFCは、簡単に破壊可能なCopyフィールドへの割り当ても安全にします（https://github.com/rust-lang/rust/issues/32836#issuecomment-281296416、httpsを参照）。 ：//github.com/rust-lang/rust/issues/32836#issuecomment-281748451）、これはFFIスタイルのユニオンにも影響します。

このテキストは、安定化に必要なドキュメントも提供します。
「概要」セクションは本にコピーして貼り付け、「詳細設計」はリファレンスに貼り付けることができます。

ping @nikomatsakis

このようなものを言語の一部として本当に追加する必要がありますか？ 少しのunsafeとptr::write()を使用して、和集合の実装をノックアップするのに約20分かかりました。

use std::mem;
use std::ptr;


/// A union of `f64`, `bool`, and `i32`.
#[derive(Default, Clone, PartialEq, Debug)]
struct Union {
    data: [u8; 8],
}

impl Union {
    pub unsafe fn get<T>(&self) -> &T {
        &*(&self.data as *const _ as *const T)
    }

    pub unsafe fn set<T>(&mut self, value: T) {
        // "transmute" our pointer to self.data into a &mut T so we can 
        // use ptr::write()
        let data_ptr: &mut T = &mut *(&mut self.data as *mut _ as *mut T);
        ptr::write(data_ptr, value);
    }
}


fn main() {
    let mut u = Union::default();
    println!("data: {0:?} ({0:#p})", &u.data);
    {
        let as_i32: &i32 = unsafe { u.get() };
        println!("as i32: {0:?} ({0:#p})", as_i32);
    }

    unsafe {
        u.set::<f64>(3.14);
    }

    println!("As an f64: {:?}", unsafe { u.get::<f64>() });
}

内部配列が最大型のサイズであることを確認する以外は、そのようなものを生成できるマクロを誰かが書くのは難しいことではないと思います。 次に、私の完全に一般的な（そして恐ろしく危険な） get::<T>()代わりに、取得および設定できるタイプを制限する特性を追加できます。 名前付きフィールドが必要な場合は、特定のgetterメソッドとsetterメソッドを追加することもできます。

私は彼らがこのような何かを書くかもしれないと思っています：

union! { Foo(u64, Vec<u8>, String) };

私のポイントは、これは、すでにかなり複雑な言語に構文と複雑さを追加する代わりに、ライブラリの一部として非常に実行可能に実行できることです。 さらに、procマクロを使用すると、まだ完全に安定していない場合でも、すでにかなり可能です。

@ Michael-F-Bryanただし、定数size_ofまだありません。

@ Michael-F-Bryan [u8]配列を用意するだけでなく、正しい配置を取得する必要もあります。 実際、私はすでにマクロを使用して共用体を処理していますが、定数size_ofとalign_ofがないため、手動で正しいスペースを割り当てる必要があります。さらに、宣言型マクロには使用可能なID連結がないためです。ゲッターとセッターの両方の名前を手動で指定する必要があります。 ユニオンを初期化するだけでも、最初にデフォルト値で初期化してから、必要なバリアントに値を設定する必要があるため、現時点では困難です（または、定義でさらに冗長なユニオンを構築するための別のメソッドセットを追加する必要があります組合の）。 それは全体的にはるかに多くの作業であり、組合のネイティブサポートよりもエラーが発生しやすく、醜いです。 この機能が非常に重要である理由を理解できるように、RFCとそれに付随する説明を読む必要があるかもしれません。

アライメントについても同じです。

synが存在するようになった今、IDの連結はそれほど難しくないはずだと思います。 渡されたASTで操作を実行できるため、2つのIDを取得し、それらの文字列表現を抽出して（ IdentはAsRef<str>実装します）、新しいIdentを作成できます。 Ident::From<String>()を使用した2つの連結です。

RFCは、既存のマクロ実装の使用がいかに面倒であるかについて多くのことを述べていますが、最近作成されたsynやquoteようなクレートにより、procマクロの実行がはるかに簡単になりました。 それは人間工学を改善し、エラーが発生しにくくするのに大いに役立つと思います。

たとえば、ユニオンの内部バッファをゼロにするMyUnion::default()を作成し、次にfn MyUnion::new<T>(value:T) -> MyUnion 。ここで、 Tには特性がバインドされているため、正しい型でのみ初期化できます。 。

配置とサイズに関して、標準ライブラリ（つまり、 std :: mem :: align_of（）とその仲間）のmemモジュールを使用できますか？ 私が提案していることはすべて、マクロ展開時にそれらを使用して、必要なサイズと配置を把握できるかどうかにかかっていると思います。 ユニオンが使用される時間の99.9％はとにかくプリミティブ型で行われるので、型の名前を取り、その配置またはサイズを返すヘルパー関数を記述できると思います（おそらくコンパイラーに尋ねますが、それはもっと実装の詳細）。

確かに、組み込みのパターンマッチングは非常に便利ですが、ほとんどの場合、FFIで使用するユニオンは、とにかく薄い抽象化レイヤーにラップされます。 したがって、if / elseステートメントをいくつか使用するか、ヘルパー関数を使用することで解決できる可能性があります。

配置とサイズに関して、標準ライブラリのmemモジュール（つまり、std :: mem :: align_of（）とその仲間）を使用できますか？

これは、クロスコンパイルのコンテキストでは機能しません。

@ Michael-F-Bryan https://github.com/rust-lang/rfcs/pull/1444の歴史の中で、これらすべての議論とその他多くの議論が行われました。 すでに述べたものに加えて、特定の懸念への対応を要約すると、すべてのターゲットプラットフォーム/コンパイラのパディングとアライメントのルールを再実装し、FFIコード全体で厄介な構文を使用する必要があります（

また：

ユニオンが使用される時間の99.9％は、とにかくプリミティブ型で実行されます

まったく真実ではありません。 Cコードは、「構造体の結合の構造」パターンを広範囲に使用します。このパターンでは、ほとんどの結合フィールドが異なる構造体タイプで構成されています。

@petrochenkovのコメントごとに@rfcbotfcpマージhttps://github.com/rust-lang/rust/issues/32836#issuecomment-279256434

ボットをトリガーするだけで、追加するものは何もありません

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

• [x] @aturon
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [x] @withoutboats

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

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

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

PSA：「Unions1.2」RFCを更新して、FFIスタイルのユニオンに影響を与えるもう1つの変更を加えます。安全な割り当てを、簡単に破壊できるユニオンのフィールドに「将来の方向性」から適切なRFCに移動します。

union.trivially_destructible_field = 10; // safe

なぜ：

• 自明に破壊可能なユニオンフィールドへの割り当ては、ユニオンの解釈に関係なく、無条件に安全です。
• ユニオン関連のunsafeブロックの約半分が削除されます。
• 安定したコードではunused_unsafe警告/エラーが多数発生する可能性があるため、後で行うのは難しくなります。

@petrochenkov 「自明に破壊可能なユニオンフィールド」、または「完全に自明に破壊可能なフィールドを持つユニオン」を意味しますか？

解釈を選択する読み取り時に、すべての危険な動作が発生することを提案していますか？ たとえば、列挙型と他のフィールドを含むユニオンがあり、ユニオン値に無効な判別式が含まれていますか？

もっともらしいと思われる高レベルで。 安全ではないと思われることはいくつか許可されますが、デストラクタのバイパスやメモリリークなど、Rustでは一般的に許可されません。 低レベルでは、私はその音を検討することを躊躇します。

そのサブセットを安定させることについては大丈夫だと思います。 このUnions1.2 RFCについての私の意見は、読む時間がなかったのでまだわかりません。 場合によっては、フィールドへの安全なアクセスを許可することについてどう思うかわかりません。 振り返ってみると、何が安全でないか（ポインタを逆参照するだけ）の「最小限の」概念を作成するための努力は間違いだったように感じます。 LLVMと複雑な方法で相互作用します。 ここでもそうかもしれない気がします。 言い換えれば、安全でないコードガイドラインの進展に合わせて、 unsafeに関するルールを撤回することもできます。

@joshtriplett
「自明に破壊可能なフィールド」、私は言い回しを微調整しました。

解釈を選択する読み取り時に、すべての危険な動作が発生することを提案していますか？

はい。 書き込みだけでは、その後の読み取りなしでは危険なことは何も起こりません。

編集：

振り返ってみると、何が安全でないか（ポインタを逆参照するだけ）の「最小限の」概念を作成するための私たちの努力は間違いだったように感じます

ああ。
安全な書き込みは、安全性に対する現在のアプローチと完全に一致していますが、それを変更する場合は、おそらく待つ必要があります。

私はこのサブセットを安定させることに満足していません。 通常、サブセットを安定させると、それは構文サブセットまたは少なくともかなり明白なサブセットになります。 このサブセットは私には少し複雑に感じます。 機能について未決定で、現在の実装を安定させる準備ができていない場合は、全体をしばらく不安定なままにしておきたいと思います。

@nrc
まあ、サブセットはかなり明白です-「FFIユニオン」、「Cユニオン」、または「C ++ 11以前のユニオン」-構文的でなくても。 私の最初の目標は、このサブセットをできるだけ早く（理想的にはこのサイクルで）安定させて、 winapiようなライブラリで使用できるようにすること
残りのサブセットとその実装について特に疑わしいことは何もありません。緊急ではなく、「Unions1.2」RFCのプロセスが完了するまで不明確な時間を待つ必要があります。 私の期待は、最初のサブセットの安定化後、1、2、または3サイクルで残りの部分を安定化することです。

安全なフィールド割り当てについては、究極の議論があると思います。
安全でないフィールドの割り当て

unsafe {
    u.trivially_destructible_field = value;
}

安全な完全な組合の割り当てに相当します

u = U { trivially_destructible_field: value };

ただし、安全バージョンは、 trivially_destructible_field外側のuのバイトをundefで上書きするため、逆説的に安全性が低くなりますが、フィールド割り当てでは、それらをそのままにしておくことが保証されます。

@petrochenkovその極端なものはsize_of_val(&value) == 0ですよね？

2つのスニペットの同等性は、問題のフィールドが
「自明に破壊可能」ですね

その意味で、これらのような割り当てを安全に行うことは、一部の場合に限られます
私には非常に矛盾しているようです。

2017年2月22日14：50、「VadimPetrochenkov」 [email protected]
書きました：

安全なフィールド割り当てについては、究極の議論があると思います。
安全でないフィールドの割り当て

安全ではない{
u.trivially_destructible_field = value;
}

安全な完全な組合の割り当てに相当します

u = U {trivially_destructible_field：value};

ただし、安全なバージョンは逆説的に安全性が低くなります。
trivially_destructible_fieldの外側のuのバイトをundefで上書きします。
フィールド割り当てには、それらをそのままにしておくことが保証されています。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/32836#issuecomment-281660298 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AApc0lUOXLU5xNTfM5PEfEz9nutMZhXUks5rfC8UgaJpZM4IDXsj
。

@eddyb

その極端な例はsize_of_val（＆value）== 0ですよね？

うん。

@nagisa
誤検知の大部分を排除する1つの追加の単純なルールが非常に一貫性がない理由がわかりません。 「一部のケースのみ」は、特にすべてのFFI組合を対象としています。
「非常に一貫性がない」というのは大きな過大評価だと思います。 「 mut変数のみを割り当てることができますか？ひどい矛盾！」ほど大きくはありませんが、それでもこの方向に進んでいます。

@petrochenkovはそのような場合を考慮してください：

// Somebody Somewhere in some crate (v 1.0.0)
struct Peach; // trivially destructible
union Banana { pub actually: Peach }

// Somebody Else in their dependent crate
extern some crate;
fn somefn(banana: &mut Banana) {
    banana.actually = Peach;
}

トレイトの実装を追加することは一般的に重大な変更ではないため、Somebody Somewhere氏は、次の実装を追加することをお勧めします。

impl Drop for Peach { fn drop(&mut self) { println!("Moi Peach!") }

そして、1.1.0（1.0.0 AFAIKと互換性のあるsemver）バージョンのクレートをリリースします。

突然、誰か他の人のクレートがコンパイルされなくなりました。

fn somefn(banana: &mut Banana) {
    banana.actually = Peach; // ERROR: Something something… unsafe assingment… somewhat somewhat trivially indestructible… 
}

したがって、ユニオンフィールドへの安全な割り当てを許可することは、 mutローカルのみがミューテーション可能であるほど簡単ではない場合があります。

この例を書き留めていると、正直なところ、これに対してどのスタンスを取るべきかわからなくなってきました。 一方で、実装の追加は一般的に重大な変更ではないという特性を維持したいと思います（XIDの潜在的なケースを無視します）。 一方、ユニオンのフィールドを自明に破壊可能なものから自明に破壊できないものに変更することは、明らかに見落としがちなsemverの互換性のない変更であり、提案されたルールはこれらの非互換性をより明確にします（割り当てが安全でないブロックにない限り）既に）。

@nagisa
これは良い議論です、私は互換性について考えていませんでした。

しかし、問題は解決できるようです。 互換性の問題を回避するには、コヒーレンスと同じことを行います-否定的な推論を避けます。 つまり、「trivially-destructible」==「コンポーネントはDrop実装しません」を最も近い正の近似に置き換えます-「 Copy実装します」。
Copyタイプは、後方互換性のあるCopy実装を解除できません。また、 Copyタイプは、特にFFIユニオンのコンテキストでは、依然として「自明に破壊可能な」タイプの大部分を表します。

Drop実装は、すでに下位互換性がなく、これはユニオン機能とは何の関係もありません。

// Somebody Somewhere in some crate (v 1.0.0)
struct Apple; // trivially destructible
struct Pineapple { pub actually: Apple }

// Somebody Else in their dependent crate
extern some crate;
fn pineapple_to_apple(pineapple: Pineapple) -> Apple {
    pineapple.actually
}

// some crate v 1.1.0
impl Drop for Pineapple { fn drop(&mut self) { println!("Moi Pineapple!") }

fn pineapple_to_apple(pineapple: Pineapple) -> Apple {
    pineapple.actually // ERROR: can't move out of Pineapple
}

これは、ドロップドロップの暗黙的なコピーを実装するように聞こえます。 そしてコピー
頼ることができます。

10：11 AMで水曜日、2017年2月22日には、jethrogb [email protected]は書きました：

Dropの実装はすでに下位互換性がなく、これには
ユニオン機能とは何の関係もありません。

//誰かが木枠のどこかにいる（v 1.0.0）
Appleを構築する; //簡単に破壊可能
struct Pineapple {実際のパブ：Apple}

//依存する木枠にいる他の誰か
いくつかの木枠を外します。
fn pineapple_to_apple（pineapple：Pineapple）-> Apple {
パイナップル。
}

//いくつかのクレートv1.1.0
impl Drop for Pineapple {fn drop（＆mut self）{println！（ "Moi Pineapple！"）}

fn pineapple_to_apple（pineapple：Pineapple）-> Apple {
banana.actually //エラー：パイナップルから移動できません
}

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

@jethrogb
この問題について言及したかったのですが、特別な前提条件がほとんどないため、言及しませんDropを実装する構造体にはパブリックフィールドが必要であり、そのフィールドはCopyはなりません。 ユニオンケースは、すべての構造体に無条件に影響します。

@petrochenkovおそらく、組合を作ることは安全ではないはずだという議論だと思います:)

@petrochenkovサブセットを安定させるための開発とnightly-user-experienceパスは何ですか？ サブセットに最初に新しい機能ゲートを追加して、サブセットが安定する前に人々がサブセットの使用を具体的に体験できるようにしますか？

@pnkfelix
私が想定したのは、このサブセットに#[feature(untagged_unions)]を要求するのをやめることであり、新機能やその他の官僚機構は必要ありません。
FFIスタイルのユニオンが最も頻繁に使用される種類のユニオンであると考えられているため、新しい機能は、安定化の直前に破損が保証されることを意味します。これは、煩わしいと思います。

アラインメントとパッキングの属性はまだ実装されていないため（安定化する必要はありません）、これを安定化する必要性はあまりありません。

@ retep998
梱包？ #[repr(packed)]を意味する場合は、現在、ユニオンでサポートされています（ align(>1)属性とは異なります）。

@petrochenkov #[repr(packed(N))] 。 winapiでは、1以外のパッキングがかなり必要です。 特にユニオンでこれらのものをサポートする必要があるわけではありません。これらすべてを同時に取得できない限り、新しいメジャーバージョンにジャンプしてRustの最小要件を増やしたくありません。

ここでプレイの状態を少し明確にするために：

現在のFCP提案は、純粋なCopy組合のみを対象としています。 私の知る限り、基本的に「安定させるべきか」以外の未解決の質問はありません。 FCPへの動議以来の議論はすべて@petrochenkovの新しいRFCについて

@nrcと@ nikomatsakis 、IRCでの議論から、あなたは両方ともあなたのボックスをチェックする準備ができていると思いますが、私はあなたにそれを任せます;-)

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

@petrochenkov
これは私が最近浮かんだアイデアから利益を得るだろうと私には思えます。 （https://internals.rust-lang.org/t/automatic-marker-trait-for-unconditionally-valid-repr-c-types/5054）

ユニオンを念頭に置いて提案されていませんが、説明されている特性Plain （バイクシェディングの対象）により、 Plainタイプのみで構成されるユニオンを安全性を損なうことなく使用できます。 これは、メモリ内の任意のビットパターンが同等に有効であるというプロパティを体系化するため、メモリをゼロにすることを強制することで初期化の問題を解決でき、読み取りでUBを呼び出せないようにします。

FFIのコンテキストでは、定義されたPlainあることも、多くの場合、そのようなコードが適切であるための事実上の要件ですが、 Plainタイプが役立つ場合はまれであり、設定が困難です。安全に。

名前付きの特性が実際に存在することはさておき、この機能を2つに分割するのが賢明かもしれません。 資格のないunionが要件を実施し、安全性を損なうことなく使用できるようにし、 unsafe unionはコンテンツの要件を緩和し、ユーザーの頭痛の種を増やします。 そうすれば、将来的にもう一方を追加する方法を妨げることなく、どちらかを安定させることができます。

@ le-jzr
これは組合と十分に直交しているようです。
近い将来、 PlainをRustに受け入れる可能性は低いと推定します。+ユニオンフィールドへのアクセスを安全にすることは、多かれ少なかれ下位互換性があります（完全にリントが原因ではありません）。したがって、ユニオンを遅らせることはありません。それに。

@petrochenkov私は、私の提案が閉鎖されるのを待つのを組合に遅らせることを提案しているのではなく、そのような可能な制限の_存在_をそれ自体で検討することを提案している。 将来、ユニオンフィールドへのアクセスを安全に行うと、言語の不整合が増えるため、障害に直面する可能性があります。 特に、フィールドアクセスの安全性がフィールドごとに異なるようにすることは醜いようです。

したがって、宣言をunsafe unionにするという私の提案は、新しいキーワードを追加せずに、無条件に安全に使用できるバージョンを後で導入できるようにするためです。 ほとんどのユースケースでは、完全に安全に使用できるバージョンで十分であることに注意してください。

編集：私が言うことを明確にしようとしました。

この可能性が現在および将来の設計に情報を与える可能性があるもう1つの場所は、初期化です。 無条件に安全な結合を行うには、そのために予約されているメモリのスパン全体をゼロにする必要があります。 現在のバージョンでも、これを確実にすると、潜在的なUBシナリオが削減され、共用体の使用が容易になります。

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

マージするFCPが完了したので、次のステップは何ですか？ これを1.19の間安定させるといいでしょう。

@bstrieつまり、機能を安定させたい

誰かがその@rfcbotメッセージ（ここのソースコード）にさらに詳細を追加できれば素晴らしいでしょう。 プロセスに不慣れな人が飛び込んで物事を進めるのが簡単になる可能性があります。

これを1.19にするための道筋は明らかです。 誰かがそれをフックしていますか？ cc @joshtriplett

NonZero列挙型レイアウトの最適化はunionを通じて適用されることが保証されていますか？ たとえば、 Option<ManuallyDrop<&u32>>はNoneをnullポインタとして表すべきではありません。 Some(ManuallyDrop::new(uninitialized::<[Vec<Foo>; 10]>())).is_some()は、初期化されていないメモリを読み取ってはなりません。

https://crates.io/crates/nodrop（https://crates.io/crates/arrayvecで使用）には、これに対処するためのハックがあります。

@SimonSapin
これは現在、RFCで未解決の質問としてマークされ
現在の実装では、このプログラム

#![feature(untagged_unions)]

struct S {
    _a: &'static u8
}
union U {
    _a: &'static u8
}

fn main() {
    use std::mem::size_of;
    println!("struct {}", size_of::<S>());
    println!("optional struct {}", size_of::<Option<S>>());
    println!("union {}", size_of::<U>());
    println!("optional union {}", size_of::<Option<U>>());
}

プリント

struct 8
optional struct 8
union 8
optional union 16

つまり、最適化は実行されません。
cc https://github.com/rust-lang/rust/issues/36394

これで1.19になる可能性は低いです。

@brson

これで1.19になる可能性は低いです。

安定化PRが統合されます。

タグなしのユニオンが1.19で出荷されるようになりました（一部はhttps://github.com/rust-lang/rust/pull/42068から）-この問題に残っているものはありますか、それとも閉じる必要がありますか？

@jonathandturner
Copyフィールドを持つユニオンの全世界がまだあります！
進行状況は、ほとんどの場合、明確化/文書化RFC（https://github.com/rust-lang/rfcs/pull/1897）でブロックされています。

8月以降、 Copyフィールドを持つ組合で進展はありましたか？ Unions 1.2 RFCは行き詰まっているようです（impl期間が原因だと思いますか？）

ユニオンで?Sizedタイプを許可すると、単一タイプのユニオンの場合のみ、 https ： ます。

`` `錆
ユニオンManuallyDrop{{
値：T
}

@mikeyhew本当に必要なのは、多くても1つのタイプのサイズを変更できないことだけです。

unionを使用していくつかのRustコードを見ていますが、それが未定義の動作を呼び出すかどうかわかりません。

参照[items :: unions]は次のことだけを述べています。

ユニオンが保持する現在の値と十分にレイアウト互換性がある場合は、非アクティブなフィールドにも（同じ構文を使用して）アクセスできます。 互換性のないフィールドを読み取ると、未定義の動作が発生します。

しかし、 [items :: unions]にも[type_system :: type_layout]にも「レイアウト互換」の定義が見つかりません。

RFCを調べても、「レイアウト互換」の定義を見つけることができませんでした。RFC1897 ：Unions 1.2 （マージされていない）で機能する必要があるものと機能しないものの手で振った例だけです。

RFC1444：ユニオンは、未定義の動作を呼び出さない限り、ユニオンをそのバリアントに変換することを許可しているようですが、そうでない場合は、RFCのどこにも見つかりません。

ユニオンを使用するコードの一部がどこかに書き留められた動作を定義しているかどうか（および定義された動作とは何か）を教えてくれる_precise_ルールはありますか？

@gnzlbg最初の概算：パディングにアクセスできない、無効な判別式を含む列挙型にアクセスできない、trueまたはfalse以外の値を含むboolにアクセスできない、無効な浮動小数点値またはシグナリング浮動小数点値にアクセスできない、およびそれらのような他のいくつかのもの。

和集合を含む特定のコードを指すと、それを調べて、未定義の処理を行っているかどうかを知ることができます。

最初の概算：パディングにアクセスできない、無効な判別式を含む列挙型にアクセスできない、trueまたはfalse以外の値を含むboolにアクセスできない、無効またはシグナリング浮動小数点値にアクセスできない、およびそれらのような他のいくつかのもの。

実際、最新のコンセンサスは、任意のフロートを読み取ることは問題ないということです（＃46012）。

もう1つの要件を追加します。ソースとターゲットの両方のユニオンバリアントは#[repr(C)]あり、構造体の場合はすべてのフィールド（および再帰的）も同様です。

@Amanieu正直に立って、ありがとう。

だから私はルールがどこにも書かれていないと思いますか？

新しいインターフェースでstdsimdを使用する方法を検討しています。 それでいくつかのエクストラを安定させない限り、次のようないくつかのsimdタイプで型のパンニングを行うためにユニオンを使用する必要があります。

https://github.com/rust-lang-nursery/stdsimd/blob/03cb92ddce074a5170ed5e5c5c20e5fa4e4846c3/coresimd/src/x86/test.rs#L17

AFAIKは、1つのユニオンフィールドを記述して別のフィールドを読み取ることは、同じ制限付きでtransmute_copyを使用するのと非常によく似ています。 これらの制限がまだ少し曖昧であるということは、組合固有ではありません。

さらに言えば、リンクした関数はtransmute::<__m128d, [f64; 2]>使用するだけで済みます。 ユニオンバージョンの方が議論の余地はありますが、少なくとも現在存在する核変換が削除されると、 A { a }.b[idx]なる可能性があります。

@rkruppe私はその糸くずを追加するためにクリップの問題を埋めました： https ：

リンクした関数は、transmute :: <__ m128d i = "8">を使用できます。

私が探しているルールは、transmuteが未定義の動作を呼び出すときだと思います（それで、それらを探しに行きます）。

ユニオンに関する言語リファレンスが、単に「レイアウトの互換性」に言及してそれを残すのではなく、トランスミュートの観点からユニオンのルールを指定していれば（トランスミュートのルールがまだ100％明確でなくても）、私は助けになったと思います。その時。 「レイアウトの互換性」から「トランスミュートが未定義の動作を呼び出さない場合、型はレイアウト互換であり、型のパンニングを介してアクセスできる」への飛躍は私には明らかではありませんでした。

明確にするために、transmute [_copy]はユニオンよりも「原始的」ではありません。 実際、transmute_copyは、文字通り、 asキャストとptr::read単なるポインターです。 transmuteさらにmem::uninitialized （非推奨）またはMaybeUninitialized （ユニオン）などを必要とし、効率のために組み込みとして実装されますが、それもタイプに要約されます-わいせつなmemcpy。 私が核変換とのつながりを描いた主な理由は、それが古く、歴史的に強調されすぎていたためです。そのため、現在、核変換に特に焦点を当てた記事や民間伝承の知識が増えています。 何が有効で何が無効であるか（および仕様で説明されるか）を決定する実際の基本概念は、値がバイトとしてメモリに格納される方法と、どのバイトシーケンスがどのタイプとして読み取るためにUBであるかです。

訂正：transmuteは、実際には初期化されていないストレージを必要としません（組み込み関数、ユニオンなどを介して）。 効率はさておき、次のようなことができます（テストされていない、恥ずかしいタイプミスが含まれている可能性があります）。

fn transmute<T, U>(x: T) -> U {
    assert!(size_of::<T>() == size_of::<U>());
    let mut bytes = [0u8; size_of::<U>()];
    ptr::write(bytes.as_mut_ptr() as *mut T, x);
    mem::forget(x);
    ptr::read(bytes.as_ptr() as *const U)
}

核変換の唯一の「魔法の」部分は、コンパイル時に型パラメーターが同じサイズになるように制約できることです。

参照およびUnions1.2 RFCは、一般的な核変換の規則が決まっていないため、この問題について意図的にあいまいになっています。
その意図は、「 repr(C)ユニオンについては、サードパーティのABI仕様を参照してください。 repr(Rust)ユニオンについては、レイアウトの互換性はほとんど指定されていrepr(C) （そうでない場合）」。

ドロップフィールドを持つユニオンのドロップチェックセマンティクスを再検討するには遅すぎますか？

元の問題は、 ManuallyDropを追加すると、ジョセフィンが不健全になることです。これは、最初にデストラクタを実行せずにバッキングストアを再利用せずに、永続的に借用した値に依存していたためです。

簡略化された例はhttps://play.rust-lang.org/?gist=607e2dfbd51f4062b9dc93d149815695&version=nightlyにあります。 アイデアは、タイプPin<'a, T>があり、メソッドpin(&'a self) -> &'a Tあり、その安全性は「 pin.pin()呼び出した後、ピンを支えるメモリが再利用された場合、不変条件に依存する」というものです。ピンのデストラクタが実行されている必要があります。」

この不変条件は、 #[allow(unions_with_drop_fields)]が追加されるまでRustによって維持され、 ManuallyDrop https：//doc.rust-lang.org/src/core/mem.rs.html#949によって使用されました

ドロップチェッカーがドロップフィールドを持つユニオンにDropimplがあると見なした場合、不変条件は復元されます。 これは重大な変更ですが、実際のコードが現在のセマンティクスに依存しているとは思えません。

IRCの会話： https ：

ジョセフィンの問題： https ：

cc： @nox @eddyb @pnkfelix

元の問題は、ManualDropを追加すると、Josephineが（かなりいたずらに）デストラクタを実行せずにバッキングストアを再利用せずに永続的に借用した値に依存していたため、不健全になることです。

デストラクタの実行は保証されていません。 Rustはそれを保証するものではありません。 試行しますが、たとえば、 std::mem::forgetは安全な関数になりました。

ドロップチェッカーがドロップフィールドを持つユニオンにDropimplがあると見なした場合、不変条件は復元されます。 これは重大な変更ですが、実際のコードが現在のセマンティクスに依存しているとは思えません。

ユニオンのどのフィールドが有効かわからないことが主な理由で、ユニオンは安全ではありません。 ユニオンは自動Drop implを持つことはできません。 このようなimplが必要な場合は、 Drop implのunionフィールドが有効かどうかを知る必要があるという意味を考慮して、手動で記述する必要があります。

ここに一つの明確化：私は、私たちが今までと組合許可しなければならないとは考えていないDrop少なくとも警告・バイ・デフォルト糸くず、そうでない場合は、エラー・バイ・デフォルトのlintせずに、デフォルトでフィールドを。 unions_with_drop_fieldsは、安定化プロセスの一部として消えてはなりません。

編集：おっと、「閉じてコメント」を押すつもりはありませんでした。

@joshtriplettはい、Rustはデストラクタが実行されることを保証しませんが、mem::forgetが存在する場合でも当てはまります。これは、永続的に借用した値で呼び出すことができないためです。

これはJoephineがややいたずらに頼っていたものですが、ドロップチェッカーがunions_with_drop_fields処理する方法のため、もはや真実ではありません。

allow(unions_with_drop_fields)が安全でない注釈であると見なされた場合は問題ありません。これは大幅な変更ではなく、AFAICTです。 deny(unsafe_code)をチェックするためにallow(unions_with_drop_fields) deny(unsafe_code)が必要です。

@asajeffrey私はまだPinことを理解しようとしています...したがって、例に正しく従えば、これが「機能する」理由は、 fn pin(&'a Pin<'a, T>) -> &'a Tが借用を次のように強制するためです。タイプに注釈が付けられたライフタイム'aであり、そのライフタイムがさらに不変である限り。

それは興味深い観察です！ 私はこのトリックに気づいていませんでした。 私の直感では、これは「偶然」に機能します。つまり、安全なRustは、デストラクタの実行を防ぐ方法を提供しませんが、それは「契約」のこの部分にはなりません。 特に、 https：//doc.rust-lang.org/nightly/reference/behavior-considered-undefined.htmlにはリークがリストされていません。

IMOは、偶然に機能するか、意図的に機能するかは関係ありません。 ManuallyDrop存在する前に（安全でないコードを実装する必要があります）、このトリックでDrop実行することを回避する方法はありませんでした。そして、今ではそれを信頼することはできません。

ManuallyDrop追加すると、基本的にRustの巧妙な動作が失われ、そもそも信頼すべきではないと言ったのは、循環論法のように思えます。 ManuallyDropがPin::pin呼び出しを許可しなかった場合、 Pin::pin呼び出しを不健全にする他の方法はありますか？ そうは思いません。

rustcが偶然に提供するすべての保証を今すぐ維持することを約束できるとは思いません。 これらの保証が何であるかわからないので、私たちはポークで豚を安定させます（わかりました、このイディオムが理にかなっていることを願っています...それは辞書が私の母国語のイディオムと一致することを教えてくれます。これは文字通り「バッグの中の猫」;）-私が言いたいのは、私たちが何を安定させるかについての手がかりがないということです）。

また、これは両刃の剣です-私たちが提供することを決定したすべての追加の保証は、安全でないコードが処理しなければならないものです。 ちょうどだけでなく、新しい危険なコードを有効にする既存の危険なコード（意識せずに黙ってどこかcrates.io上に座っを）破ることが、新たな保証を発見するので（後者は、ここではそうでした）。

たとえば、字句の有効期間によって、非字句の有効期間によって破損する安全でないコードが有効になることが非常に考えられます。 現在、すべてのライフタイムは適切にネストされていますが、安全でないコードがこれを悪用する方法があるのではないでしょうか。 非字句のライフタイムでのみ、オーバーラップするライフタイムが存在する可能性がありますが、どちらも他に含まれていません。 これはNLLに重大な変化をもたらしますか？ 私はそうしないことを望みます！

ManualDropがPin :: pinの呼び出しを許可しなかった場合、Pin :: pinの呼び出しを不健全にする他の方法はありますか？ そうは思いません。

unsafeコードを使用すると、次のようになります。 したがって、このPinトリックサウンドを宣言することで、 ManuallyDropが問題ないと判断した場合に聞こえる、安全でないコードunsoundを宣言することになります。

私たちが説明したのは、RustをGCと統合するための非常に人間工学的な方法です。 私が言うことをしようとしていることは、これはそれが働いていたということだけで事故だったと私は労働組合を拘束しないため任意のユースケースを見つけることができないときに我々は、それを忘れなければならないということを私たちに伝えるために私に間違って聞こえるということですDropここで@asajeffreyによって説明されているDropフィールド、およびこれが本当にジョセフィンを壊す唯一の疣贅である場合。

ManuallyDropなくても、誰かがそれが不健全

私が言おうとしているのは、これがうまくいったのは単なる事故だったと私たちに言うのは間違っているように聞こえるということです

このトリックが「設計」された兆候は見当たらないので、それを事故と呼ぶのはかなり公正だと思います。

そしてそれを忘れるべきだと

この部分は私の個人的な直感であることを明確にすべきでした。 これを「幸せな事故」と宣言し、実際に保証することも合理的な行動のポイントになると思います。他のすべてのunsafeコードがこの保証を尊重していると合理的に確信している場合は、この保証を提供することは、 ManuallyDropユースケースよりも重要です。 これは、リークポカリプスと同様にトレードオフであり、ケーキを食べて食べることもできません（現在のAPIでRcとdrop両方を持つことはできません-ベースのスコープスレッド。 ManuallyDropとPin両方を持つことはできないため、どちらの方法でも決定する必要があります。

とはいえ、ここで提供されている実際の保証を正確に表現するのは難しいと思います。そのため、個人的には「 ManuallyDropは問題ない」という側面に傾倒しています。

他のすべてのunsafeコードがこの保証を尊重し、この保証を提供することがManuallyDropユースケースよりも重要であると合理的に確信している場合。 これは、リークポカリプスと同様にトレードオフであり、ケーキを食べて食べることもできません（現在のAPIでRcとdrop両方を持つことはできません-ベースのスコープスレッド。 ManuallyDropとPin両方を持つことはできないため、どちらの方法でも決定する必要があります。

十分に公平です、私は心からそれに同意します。 @asajeffreyが最終的に未定義の動作として説明したことを考慮すると、 dropベースのスコープ付きスレッドAPIが返される可能性があることに注意してください。

私が理解している限り、アランの提案はManuallyDropを削除することではなく、dropckにそれ（およびDropフィールドを持つ他のユニオン）にデストラクタがあると想定させることだけです。 （そのデストラクタはたまたま何もしませんが、その単なる存在は、dropckが受け入れるまたは拒否するプログラムに影響を与えます。）

ManualDropがなくても、誰かがそれが不健全であると示すことができれば、私はそれを忘れて幸せです。

これが適格かどうかはわかりませんが、これが私の最初の試みです。 union以前のRustで機能するManuallyDropようなばかげた実装です。

pub mod manually_drop {
    use std::mem;
    use std::ptr;
    use std::marker::PhantomData;

    pub struct ManuallyDrop<T> {
        data: [u8; 32],
        phantom: PhantomData<T>,
    }

    impl<T> ManuallyDrop<T> {
        pub fn new(x: T) -> ManuallyDrop<T> {
            assert!(mem::size_of::<T>() <= 32);
            let mut data = [0u8; 32];
            unsafe {
                ptr::copy(&x as *const _ as *const u8, &mut data[0] as *mut _, mem::size_of::<T>());
            }
            mem::forget(x);
            ManuallyDrop { data, phantom: PhantomData }
        }

        pub fn deref(&self) -> &T {
            unsafe {
                &*(&self.data as *const _ as *const T)
            }
        }
    }
}

（ええ、私はおそらくアライメントを正しくするためにもう少し作業をしなければなりませんが、それはいくつかのバイトを犠牲にすることによっても行うことができます。）
これが壊れていることを示す遊び場Pin ： https ：

これは私が上記の両刃の剣によって意味したものです-私が見る限り、私のManuallyDropは私たちが出したすべての規則を尊重します。 したがって、互換性のない安全でないコードが2つあります。 ManuallyDropとPinです。 「正しい」のは誰ですか？ Pinは、これまでに行ったことのない保証に依存しているため、ここでは「間違っている」と思いますが、これは判断の呼びかけであり、証拠ではありません。

今、それは興味深いです。 固定機能の一部のバージョンでは、 Pin::pinは&'this mut Pin<'this, T> Pin::pin取りますが、 ManuallyDropがDerefMut implを持つことは不合理ではありません。 ？

これは、 @ RalfJungが（当然のことながら） &mut取るpinメソッドでPinを破ることを示す遊び場です。

https://play.rust-lang.org/?gist=5057570b54952e245fa463f8d7719663&version=nightly

ManualDropがDerefMutimplを持つことは不合理ではありませんよね？

ええ、この例に必要なAPIを追加しました。 明らかなderef_mutは問題なく機能するはずです。

私が理解している限り、Alanの提案は、ManuallyDropを削除することではなく、dropckにそれ（およびDropフィールドを持つ他のユニオン）にデストラクタがあると想定させることだけです。 （そのデストラクタはたまたま何もしませんが、その単なる存在は、dropckが受け入れるまたは拒否するプログラムに影響を与えます。）

ああ、私はそれを見逃していました。 申し訳ありません。 私の例に以下を追加しても、それは機能し続けます：

    unsafe impl<#[may_dangle] T> Drop for ManuallyDrop<T> {
        fn drop(&mut self) {}
    }

#[may_dangle]を削除した場合にのみ、Rustはそれを拒否します。 したがって、少なくとも、上記のコードが違反しているというルールを考え出す必要があります。「これと互換性のないサウンドにしたいコードが存在する」と言うだけでは、それが原因で不正な呼び出しになります。いくつかのコードを見て、それが健全であるかどうかを確認することはほとんど不可能です。

この「偶発的な保証」について私が最も不安に思うのは、これが機能する正当な理由が1つも見当たらないことだと思います。 Rustでの接続方法によってこれが維持されますが、リークを防ぐためではなく、デッドデータへの誤った参照（デストラクタで一般的な問題）を回避するためにdropckが追加されました。 以下のための推論Pin仕事には基づいていない「ここではかなり明確にパーマ借りデータが漏洩することはできないと言うことを、錆のコンパイラでは、いくつかのメカニズム、あるいはいくつかのタイプのシステムの保証である」 -それはかなり基づいています「私たちは一生懸命努力しましたが、永久に借りたデータを漏らすことができなかったので、それは大丈夫だと思います」。 健全性をこれに頼ると、かなり緊張します。 編集：コンパイラのこの部分には厄介な健全性のバグの歴史があるため、dropckが関係しているという事実は私をさらに緊張させます。 これが機能する理由は、パーマ借入が安全なdropと対立しているためと思われます。 これは本当に「永久に借りたデータで何ができるかについての徹底的な事例分析に基づく推論」のようです。

さて、公平を期すために、内部の可変性について同様のことを言うことができます-適切なAPIを選択すれば、共有参照を介して変更を許可することが実際に安全に機能する場合があります。 ただし、これを機能させるには、最適化と衝突するため、コンパイラでの明示的なサポート（ UnsafeCell ）が実際に必要でした。また、内部の可変性がないと健全であるが、内部の可変性では健全ではない安全でないコードがあります。 もう1つの違いは、内部の可変性が最初から（または非常に早い段階から-これはRustコミュニティでの私の時間よりずっと前の）設計目標であったことです。これは「永久借りたものが漏れない」場合には当てはまりません。 そして最後に、内部の可変性については、「共有すると突然変異が危険になりますが、不可能ではありません。共有参照」APIは、一般に可変性多くの時間を費やしてきました。そのため、私が気付いていない、目前の問題についても同様に首尾一貫した状況があるかもしれません。

タイムゾーンは楽しいです、私は起きたばかりです！ ここには2つの問題（一般に不変条件、特にdropck）があるように思われるので、別々のコメントに入れます...

@RalfJung ：はい、これは安全でないRustによって維持されている不変条件に関する問題です。 Rust + stdのどのバージョンでも、信頼保証推論を使用して維持される不変のI選択肢が複数あります。 実際、互換性のないI1とI2を選択した2つのライブラリL1とL2が存在する可能性があるため、Rust + L1は安全であり、 Rust + L2は安全ですが、Rust + L1 + L2は安全ではありません。

この場合、 L1はManuallyDropあり、 L2はJosephineであり、 ManuallyDropが勝つことは明らかです。 std 、Josephineよりもはるかに強力な下位互換性の制約があります。

興味深いことに、 https：//doc.rust-lang.org/nightly/reference/behavior-considered-undefined.htmlのガイドラインは、「安全でないコードを作成する場合、安全なコードを許可できないのはプログラマーの責任です。次の動作を示します：... "つまり、これはコンテキストプロパティであり（すべての安全なコンテキストCの場合、C [P]は失敗することはありません）、バージョンに依存します（Rust + stdのv1.20の方が安全であるため） v1.18よりもコンテキスト）。 特に、安全なコンテキストC st C [Pinning]がうまくいかなかったため、ピン留めは1.20より前のRustのこの制約を実際に満たしていたと私は主張します。

ただし、これは単なる兵舎の弁護士であり、このコンテキスト定義に問題があることに誰もが同意していると思います。したがって、安全でないコードガイドラインに関するすべての議論があります。

他に何もないとしても、ピン留めは偶発的な不変条件がうまくいかないという興味深い例を示していると思います。

タグなしユニオン（したがってManuallyDrop ）が行った特定のことは、ドロップチェッカーとの相互作用ManualDropた。特に

unsafe impl<#[may_dangle] T> Drop for ManuallyDrop<T> { ... }

次に、これが許可されているかどうかについて会話することができます:)実際、この会話はhttps://github.com/rust-lang/rust/issues/から始まるmay_dangleスレッドで行われています。 34761＃issuecomment -362375924

@RalfJungコードは、 dataの実行時型がTであるが、コンパイル時型が[u8; N]という興味深いコーナーケースを示しています。 may_dangleに関する限り、どのタイプが重要ですか？

興味深いことに、 https：//doc.rust-lang.org/nightly/reference/behavior-considered-undefined.htmlのガイドラインは、「安全でないコードを作成する場合、安全なコードを許可できないのはプログラマーの責任です。これらの動作を示します：... "つまり、コンテキストプロパティです

ああ、面白い。 私はこれが明らかに十分ではないことに同意します-これは元のスコープスレッドを健全にするでしょう。 意味のあるものにするために、これは（少なくとも）安全なコードが呼び出すことを許可されている安全でないコードのセットを指定する必要があります。

個人的には、これを指定するより良い方法は、維持される不変条件を与えることだと思います。 しかし、私がRustについてのことを証明するために使用する方法論はそのような不変条件を必要とするので、私はここで明らかに偏っています。 ;）

このページに予備的であるという何らかの免責事項が含まれていないことに少し驚いています。 この議論が示すように、制限がになるかはっきりしていません。 少なくともそのドキュメントに書かれていることを実行するに

たとえば、未定義の振る舞いの制限と安全でないコードができることは同じではありません。 このトピックに関する最近の議論については、 https：//github.com/nikomatsakis/rust-memory-model/issues/44を参照してください&mut Tをmem::size_of::<T>() == 0複製しても、未定義の動作は発生しません。直接、それでも安全でないコードが行うことは明らかに違法と見なされます。 その理由は、他の安全でないコードは、その所有権の規律が尊重されることに依存している可能性があり、物事を複製することはその規律に違反するためです。

他に何もないとしても、ピン留めは偶発的な不変条件がうまくいかないという興味深い例を示していると思います。

ああ、それは確かに。 そして、将来これを回避するために何ができるのだろうか？ たぶんhttps://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.htmlに、「不変条件がrustc + libstdに保持されているからといって、安全でないコードができるという意味ではありません。それに依存します;代わりに、信頼できるいくつかの不変条件があります」？

@RalfJungはい、主にコンテキストの観察力に対して脆弱であるため、「正当性」のコンテキスト

私が求めているのは、少し揺れ動く余地を与えて、信頼保証推論のために2つの不変条件を定義できることだけです（コードはRに依存でき、Gを保証する必要があります。GはRを意味します）。 そうすれば、Rを強化してGを弱める余地があります。不変条件が1つしかない場合（つまり、R = G）、それらを変更することはできません。

定数チェックは現在、特殊なケースのユニオンフィールドではありません：（cc @solson @ oli-obk）

union Transmute<T, U> { from: T, to: U }

const SILLY: () = unsafe {
    (Transmute::<usize, Box<String>> { from: 1 }.to, ()).1
};

fn main() {
    SILLY
}

上記のコードは、miri評価エラー「non-constfn std::ptr::drop_in_place::<(std::boxed::Box<std::string::String>, ())> - shim(Some((std::boxed::Box<std::string::String>, ())))呼び出しています」を生成します。

.toのタイプがconst-checkerによって監視されるように強制するように変更します。

const fn id<T>(x: T) -> T { x }

const SILLY: () = unsafe {
    (id(Transmute::<usize, Box<String>> { from: 1 }.to), ()).1
};

結果は「デストラクタはコンパイル時に評価できません」になります。

関連する実装コードはここにあります（具体的にはrestrict呼び出し）：
https://github.com/rust-lang/rust/blob/5e4603f99066eaf2c1cf19ac3afbac9057b1e177/src/librustc_mir/transform/qualify_consts.rs#L557

＃41073のより良い分析により、ユニオンのサブフィールドに割り当てるときにデストラクタが実行されるときのセマンティクスは、安定化の準備が不十分であることが明らかになりました。 詳細については、その問題を参照してください。

ユニオンでDropタイプを完全に除外し、 ManuallyDrop個別に（lang-itemとして）実装するのは現実的ですか？ 私の知る限り、組合におけるDropの最大の動機は、 ManuallyDropようですが、それは非常に特殊なケースです。

肯定的な「ドロップなし」の特性がない場合、すべてのフィールドがCopyまたはManuallyDrop<T>形式である場合、ユニオンは整形式であると言えます。 これは、ユニオンフィールドを割り当てるときにドロップすることに関するすべての複雑さを完全に回避し（すべての可能なソリューションは驚くべきフットガンでいっぱいになると思われます）、 ManuallyDropは、プログラマーがDropを処理する必要があることを明確に示しています。 Drop実装しない」という前向きな言い方をすると、より良い。）

最初の投稿のチェックリストでは、サイズのないユニオンについてもRFCについても言及されていませんが、それでも、単一バリアントのユニオンに限定された実装があります。 これは、レイアウト最適化との相互作用と密接に関連しています。これは、単一バリアントのユニオンが何らかの意味で「有効」である必要があることを前提としているためです（ドロップされる可能性がありますが、そうではありません）。任意の奇数ビットパターン）。

これは、「拡張ポイント」であるCでユニオンが使用される方法と矛盾します（IIRC @joshtriplettがこれに全面的に言及しました）：ヘッダーファイルはユニオンの3つのバリアントを宣言する場合がありますが、これは後でバリアントを追加することで上位互換性があると見なされます（ユニオンのサイズが増加しない限り）。 ライブラリのユーザーは、タグ（別の場所にある）が現在のバリアントを知らないことを示している場合、ユニオンデータに触れないことを約束します。 重要なのは、バリアントが1つしかない場合でも、バリアントが1つしかないという意味ではありません。

チェックはよりスマートになる可能性があります。たとえば、同じクレートで宣言されている製品タイプと名目タイプを通過する可能性があります。

この述語はすでに存在しますが、バインドする特性がないため、ジェネリックスでは保守的です。
std::mem::needs_drop （ rustc実装する組み込み関数を使用）を介してアクセスできます。

@eddybは、上位互換性を考慮してneeds_dropを実行しますか、それとも他の作成を喜んで調べて、それらの型がDrop実装しているかどうかを判断しますか？ ここでの目標は、semver互換の変更から決して壊れないチェックを行うことです。たとえば、型または有効期間パラメーターがなく、プライベートフィールドのみがsemver互換である構造体にimpl Dropを追加します。

@RalfJung

これは、「拡張ポイント」であるCでユニオンが使用される方法と矛盾します（IIRC @joshtriplettがこれに全面的に言及しました）：ヘッダーファイルはユニオンの3つのバリアントを宣言する場合がありますが、これは後でバリアントを追加することで上位互換性があると見なされます（ユニオンのサイズが増加しない限り）。 ライブラリのユーザーは、タグ（別の場所にある）が現在のバリアントを知らないことを示している場合、ユニオンデータに触れないことを約束します。 重要なのは、バリアントが1つしかない場合でも、バリアントが1つしかないという意味ではありません。

これは非常に特殊なケースです。
これは、Cヘッダーから生成されたCスタイルのユニオンにのみ影響します（したがって、デストラクタはなく、すべてがCopyであり、stableで使用可能なサブセットです）。
このようなユニオンに_dummy: ()または_future: ()フィールドを簡単に追加して、デフォルトでより安全な「列挙型」モデルの恩恵を受け続けることができます。 「拡張ポイント」であるFFIユニオンは、とにかく十分に文書化する必要があるものです。

2018年4月17日午前10時08分54秒AM PDTで、ヴァディムPetrochenkovの[email protected]は書きました：

このようなユニオンに_dummy: ()または_future: ()フィールドを簡単に追加できます
デフォルトでは、より安全な「列挙型」モデルの恩恵を受け続けます。

判別式がわからない列挙型のように組合を扱うことについて人々が話しているのを見たことがありますが、私の知る限り、実際のモデルやそのような扱いについては知りません。 元の議論では、非FFI組合でさえ、非FFI組合を望んでいる動機付けのユースケースを含め、「一度に有効な複数のバリアント」モデルを望んでいました。

()バリアントをユニオンに追加しても何も変更されないはずです。また、ユニオンが期待するセマンティクスを取得するために変更する必要はあり

FFIユニオン
「拡張ポイント」であることは、十分に文書化する必要があるものです。
とにかく。

セマンティクスをできるだけ正確に文書化する必要があります。

@RalfJungいいえ、 auto traitのように動作し、すべての内部詳細を公開します。

現在、「アクティブフィールド」についていくつかの議論があり、 https： //github.com/rust-lang/rust/issues/41073#issuecomment-380291471で組合に参加してい

ユニオンは、安全でないコードがアクセスするまで、いつでも何が含まれているのかわからないまま、ビットの袋であり続ける必要があります。

これはまさに私が組合が機能することを期待する方法です。 これらは、余分なパフォーマンスを絞り出し、デストラクタなどがないCコードと対話するための高度な機能です。

私にとって、ユニオンの内容を削除したい場合は、タイプにキャスト/変換する必要があります（別のバリアントの最後にいくつかの未使用ビットがあるため、より大きくなる可能性があるため、変換できない可能性があります）ドロップする必要がある〜ドロップする必要のあるフィールドへのポインタを取得してstd::ptr::drop_in_placeを使用するか、フィールド構文を使用して値を抽出します。

私が組合について何も知らなかったとしたら、これは私が組合が機能することを期待する方法です。

例- mem::uninitializedを和集合として表す

pub union MaybeValid<T> {
    valid: T,
    invalid: ()
}

impl<T> MaybeValid<T> {
    #[inline] // this should optimize to a no-op
    pub fn from_valid(valid: T) -> MaybeValid<T> {
        MaybeValid { valid }
    }

    pub fn invalid() -> MaybeValid<T> {
        MaybeValid { invalid: () }
    }

   pub fn zeroed() -> MaybeValid<T> {
        // do whatever is necessary here...
        unimplemented!()
    }
}

fn example() {
    let valid_data = MaybeValid::from_valid(1_u8);
    // Destructor of a union always does nothing, but that's OK since our 
    // data type owns nothing.
    drop(valid_data);
    let invalid_data = MaybeValid::invalid();
    // Destructor of a union again does nothing, which means it needs to know 
    // nothing about its surroundings, and can't accidentally try to free unused memory.
    drop(invalid_data);
    let valid_data = MaybeValid::from_valid(String::from("test string"));
    // Now if we dropped `valid_data` we would leak memory, since the string 
    // would never get freed. This is already possible in safe rust using e.g. `Rc`. 
    // `union` is a similarly advanced feature to `Rc` and so new users are 
    // protected by the order in which concepts are introduced to them. This is 
    // still "safe" even though it leaks because it cannot trigger UB.
    //drop(valid_data)
    // Since we know that our union is of a particular form, we can safely 
    // move the value out, in order to run the destructor. I would expect this 
    // to fail if the drop method had run, even though the drop method does 
    // nothing, because that's the way stuff works in rust - once it's dropped
    // you can't use it.
    let _string_to_drop = unsafe { valid_data.valid };
    // No memory leak and all unsafety is encapsulated.
}

これを投稿してから編集して、作業を無駄にしないようにします。
フィールドをドロップする@SimonSapinの方法を編集します。

ユニオンの内容を削除する場合は、削除するタイプにキャスト/変換する必要があります（別のバリアントの最後に未使用のビットがあるため、変換できない可能性があります）。 、またはフィールド構文を使用して値を抽出します

（ドロップさせるだけの場合は、移動するという意味で値を抽出する必要はありません。フィールドの1つへのポインターを取得して、 std::ptr::drop_in_placeを使用できます。）

関連：定数については、現在、定数内のユニオンの少なくとも1つのフィールドが正しい必要があると主張しています： https ：

これを投稿してから編集して、作業を無駄にしないようにします。

編集内容はメール通知に反映されないことに注意してください。 コメントに大幅な変更を加える場合は、代わりに、または追加で新しいコメントを作成することを検討してください。

@derekdreery （および他のすべての人） https://internals.rust-lang.org/t/pre-rfc-unions-drop-types-and-manuallydrop/8025に対するフィードバックに興味があります

関連：定数については、現在、定数内の共用体の少なくとも1つのフィールドが正しい必要があると主張しています：＃51361

私は実装を見ましたが、議論を見ていません。 ;）

えーと…「全くチェックしないのは変に思えた」という議論。

constチェッカーで思いついたスキームを実装できれば幸いですが、私の直感では、ユニオンの1つのバリアントが完全に正しい必要があるということでした。

それ以外の場合、共用体は特定のサイズと配置で型を指定するための優れた方法であり、一部のコンパイラーは、型の固定セット間で変換するための便利さを生成しました。

ユニオンは、それらにアクセスするための便利な方法を備えた「未解釈のビットのバッグ」だと思います。 私はそれらをチェックしないことについて何も奇妙なことは見ていません。

AFAIKは、実際には、ベルリンのオールハンドで言及されている@joshtriplettのユースケースがいくつかあり、ユニオンの前半が1つのフィールドに一致し、後半が他のフィールドに一致します。

ユニオンは、それらにアクセスするための便利な方法を備えた「未解釈のビットのバッグ」だと思います。 私はそれらをチェックしないことについて何も奇妙なことは見ていません。

私はいつも、この解釈は言語の精神にいくらか反していますが。
他の場所では、静的分析を使用してフットガンを防止し、初期化されていない値または借用された値がアクセスされていないことを確認しますが、分析が突然無効になったユニオンについては、撮影してください。

それはまさにunionの目的だと思います。 つまり、すべての分析が無効になっている生のポインターもあります。 ユニオンは、生のポインタがメモリアクセスを完全に制御するのと同じように、データレイアウトを完全に制御します。 どちらも安全性を犠牲にして行きます。

また、これによりunion簡単になります。 単純であることは重要だと思います。安全でないコードが関係している場合はさらに重要です（これは常にユニオンの場合です）。 ここでは、具体的なメリットが得られる場合にのみ、余分な複雑さを受け入れる必要があります。

バッグオブビットモデルは、未知のバリアントを持つ列挙型モデルと比較して新しい機会を与えないため、ユニオンにそのコストを支払う必要はないと思います。

ここで問題となっているプロパティは、少なくとも、安全でないコードが保護手段であるのと同じくらい負担になります。 安全でない型のパンニングにユニオンを使用したいので、このプロパティを壊す可能性のあるすべての間違いを防ぐことができる静的分析はありません^1。したがって、「未知のバリアントを持つ列挙型」は、コード処理ユニオンが書き込み方法に細心の注意を払う必要があることを意味します。ユニオンまたはリスクインスタントUB。ユニオンからの読み取りに伴う安全性を実際に減らすことなく、警告できるのは、そのバリアントのいずれにも無効なユニオンがmiriで実行されている場合のみであり、実行時に発生するケースの大部分ではありません。

¹たとえば、簡単にするためにタプルがrepr（C）であると仮定すると、 union Foo { a: (bool, u8), b: (u8, bool) }使用すると、フィールドの割り当てだけで無効なものを作成できます。

@rkruppe

union Foo {a：（bool、u8）、b：（u8、bool）}

ねえ、それは私の例です:)
そして、RFC 1897のモデル（「リーフ」フラグメントの少なくとも1つbool -1、 u8 -1、 u8 -2、 bool -2は、部分的な割り当ての後で有効です）。

ユニオンを処理するコードは、ユニオンへの書き込み方法に細心の注意を払う必要があります。そうしないと、インスタントUBが危険にさらされます。

これがRFC1897のモデルのポイントです。静的チェックにより、安全な操作（割り当てや部分的な割り当てなど）によってユニオンが無効な状態になることはあり
ワイルドポインタを介した書き込みなど、ユニオンに関係のない安全でない操作のみが、ユニオンを無効にすることができます。

一方、移動チェックを行わないと、ユニオンは非常に簡単に無効状態になります。

let u: Union;
let x = u.field; // UB

これがRFC1897のモデルのポイントです。静的チェックにより、安全な操作（割り当てや部分的な割り当てなど）によってユニオンが無効な状態になることはありません。そのため、常に細心の注意を払う必要はなく、インスタントUBを取得する必要もありません。 。
ワイルドポインタを介した書き込みなど、ユニオンに関係のない安全でない操作のみが、ユニオンを無効にすることができます。

ある種の書き込みは、ユニオンに課せられた追加の不変条件に違反していないと自動的に認識できますが、それでもライターが支持する必要があるのは追加の不変条件です。 読み取りはまだ安全ではなく、読み取られるバリアントに対してビットが有効であることを手動で確認する必要があるため、これは実際にはリーダーの助けにはならず、ライターの生活を困難にするだけです。 「ビットのバッグ」も「バリアントが不明な列挙型」も、ユニオンの難しい問題、つまり、読み取りたい種類のデータを実際に格納する方法を解決するのに役立ちません。

より洗練された型チェックはDroppingにどのように影響しますか？ ユニオンを作成して所有権を取得するCに渡すと、錆びてデータを解放しようとし、おそらくダブルフリーが発生しますか？ それとも、常に自分でDrop実装しますか？

提案を理解していれば、ユニオンが「コンパイル時にバリアントが静的にチェックされる列挙型」のようなものであれば、編集するのはとてもクールです。

編集2では、ユニオンはビットの袋として開始し、後で下位互換性を保ちながら安全なアクセスを許可できますか？

そして、RFC 1897のモデルの下で有効です（「リーフ」フラグメントbool-1、u8-1、u8-2、bool-2の少なくとも1つは、部分的な割り当ての後に有効です）。

これを有効にすることにした場合、@ oli-obkはそれを反映するようにmiriのチェックを更新する必要があると思います-https ：//github.com/rust-lang/rust/pull/51361をマージすると、によって拒否されますミリ。

@petrochenkov私が理解していない部分は、これが私たちを買うものです。 実装（静的分析）と使用法（ユーザーは正確なルールを知っている必要があります）の点で、さらに複雑になります。 この余分な複雑さは、ユニオンが使用されるとき、私たちはすでに危険な状況にあるため、物事は当然より複雑になるという事実につながります。 この余分な複雑さがなぜそれだけの価値があるのか​​について、明確な動機が必要だと思います。 「言語の精神に多少違反している」というのは明確な動機ではないと思います。

私が考えることができるのは、レイアウトの最適化です。 「ビットの袋」モデルでは、組合にはニッチがありません。 ただし、プログラマーがニッチを手動で制御できるようにすることで、より適切に対処できると思います。これは、他の場合にも役立ちます。

私はここで基本的な何かが欠けていると思います。 @rkruppeに同意し
組合の難しい問題は、組合が現在保管していることを確認することです
プログラムが読み取りたいデータ。

しかし、この問題は静的分析では「ローカルに」解決することはできません。 私達
少なくともプログラム全体の分析が必要になりますが、それでも
解決するのが難しい問題。

だから...テーブルにこの問題の解決策はありますか？ または、何をしますか
提案されている正確なソリューションは実際に私たちを購入しますか？ Cから組合を得たとしましょう。
Rust and Cプログラム全体を分析せずに、提案できること
静的分析は実際に読者を保証しますか？

@gnzlbg私たちが得る唯一の保証は、 @ petrochenkovが上に書いたものだと思います

静的チェックにより、安全な操作（割り当てや部分的な割り当てなど）によってユニオンが無効な状態になることはありません。

一方、移動チェックを行わないと、ユニオンは非常に簡単に無効状態になります。

あなたの提案は悪い読み取りからも保護しません、私はそれが可能であるとは思いません。

また、「任意のフィールドに書き込むとユニオンが初期化される」という非常に基本的な「初期化」追跡を想像しました。 impl Drop for MyUnionが許可されている場合Drop実装するユニオンの場合、データ構造が既に初期化されていない限りフィールドへの書き込みを許可しないstructと同様の制限も想像しました。

@derekchiang

ユニオンはビットの袋として開始し、後で下位互換性を保ちながら安全なアクセスを許可できますか？
いいえ。ビットの袋だと言ったら、それが許可されていると仮定すると、安全でないコードが存在する可能性があります。

ユニオンが初期化されているかどうかを確認するための最低限の移動チェックには価値があると思います。 元のRFCは、任意のユニオンフィールドに初期化または割り当てると、ユニオン全体が初期化されることを明示的に指定していました。 ただし、それを超えて、rustcは、ユーザーが明示的に指定していない共用体の値について何も推測しようとすべきではありません。 ユニオンには、そのフィールドのいずれにも無効な値を含め、任意の値を含めることができます。

たとえば、そのユースケースの1つは、将来さらに多くのタグを使用して明示的に拡張可能なCスタイルのタグ付き共用体を検討することです。 ユニオンが考えられるすべてのフィールドタイプを知っていると想定してはならないことを読み取るCおよびRustコード。

@RalfJung

多分私は他の方向から始めるべきです。

このコードは1）ユニオンに対して2）非ユニオンに対して機能する必要がありますか？

let x: T;
let y = x.field;

私にとって、答えはどちらの場合も明らかな「いいえ」です。これは、 Tの「結合」性に関係なく、Rustが防止でき、防止したいエラーのクラス全体だからです。

つまり、移動チェッカーには、そのサポートを実装するための何らかのスキームが必要です。 移動チェッカー（および借用チェッカー）が一般にフィールドごとに機能することを考えると、共用体の最も単純なスキームは、「構造体と同じルール+フィールドの（非）初期化/借用もその兄弟フィールドを（非）初期化/借用する」です。 "。
この単純なルールは、すべての静的チェックを対象としています。

次に、列挙型モデルは、上記の静的チェック+もう1つの条件の結果です。
1）初期化チェックが有効で、2）安全でないコードがユニオンに属する領域に任意の無効なバイトを書き込まない場合、ユニオンの「リーフ」フィールドの1つが自動的に有効になります。 これは動的にチェックできません（少なくともフィールドが1を超え、const-evaluatorの外部にあるユニオンの場合）保証ですが、まずコードを読む人を対象としています。

たとえば、 @ joshtriplettからのこのケース

たとえば、そのユースケースの1つは、将来さらに多くのタグを使用して明示的に拡張可能なCスタイルのタグ付き共用体を検討することです。 ユニオンが考えられるすべてのフィールドタイプを知っていると想定してはならないことを読み取るCおよびRustコード。

ユニオンに「将来の拡張の可能性」のための追加フィールドが明示的にある場合、コードを読む人々にとってはるかに明確になります。

もちろん、基本的な静的初期化チェックを維持することはできますが、2番目の条件を拒否し、インスタントUBでなくても、安全でない「サードパーティ」手段を介して任意の無効な可能性のあるデータをユニオンに書き込むことができます。 そうすれば、そのダイナミックな人々をターゲットにした保証はもうありません。それは純損失になると思います。

@petrochenkov

このコードは1）ユニオンに対して2）非ユニオンに対して機能する必要がありますか？

let x: T;
let y = x.field;

私にとって、答えはどちらの場合も明らかな「いいえ」です。これは、 Tの「結合」性に関係なく、Rustが防止でき、防止したいエラーのクラス全体だからです。

同意しました。初期化されていない値をチェックするこのレベルは妥当であり、非常に実行可能です。

つまり、移動チェッカーには、そのサポートを実装するための何らかのスキームが必要です。 移動チェッカー（および借用チェッカー）が一般にフィールドごとに機能することを考えると、共用体の最も単純なスキームは、「構造体と同じルール+フィールドの（非）初期化/借用もその兄弟フィールドを（非）初期化/借用する」です。 "。
この単純なルールは、すべての静的チェックを対象としています。

構造体のルールを理解していると仮定して、これまでのところ同意しました。

次に、列挙型モデルは、上記の静的チェック+もう1つの条件の結果です。
1）初期化チェックが有効で、2）安全でないコードがユニオンに属する領域に任意の無効なバイトを書き込まない場合、ユニオンの「リーフ」フィールドの1つが自動的に有効になります。 これは動的にチェックできません（少なくともフィールドが1を超え、const-evaluatorの外部にあるユニオンの場合）保証ですが、まずコードを読む人を対象としています。

その追加条件は組合には無効です。

たとえば、 @ joshtriplettからのこのケース

たとえば、そのユースケースの1つは、将来さらに多くのタグを使用して明示的に拡張可能なCスタイルのタグ付き共用体を検討することです。 ユニオンが考えられるすべてのフィールドタイプを知っていると想定してはならないことを読み取るCおよびRustコード。

ユニオンに「将来の拡張の可能性」のための追加フィールドが明示的にある場合、コードを読む人々にとってはるかに明確になります。

これは、Cユニオンが機能する方法でも、Rustユニオンが機能するように指定された方法でもありません。 （そして、それがより明確になるのか、それとも単に異なる期待に一致するのか疑問に思います。）これを変更すると、Rust共用体は、設計および提案された目的の一部に適合しなくなります。

もちろん、基本的な静的初期化チェックを維持することはできますが、2番目の条件を拒否し、インスタントUBでなくても、安全でない「サードパーティ」手段を介して任意の無効な可能性のあるデータをユニオンに書き込むことができます。 そうすれば、そのダイナミックな人々をターゲットにした保証はもうありません。それは純損失になると思います。

これらの「安全でない「サードパーティ」とは、「FFIから組合を取得する」ことを意味します。これは完全に有効なユースケースです。

具体的な例を次に示します。

union Event {
    event_id: u32,
    event1: Event1,
    event2: Event2,
    event3: Event3,
}

struct Event1 {
    event_id: u32, // always EVENT1
    // ... more fields ...
}
// ... more event structs ...

match u.event_id {
    EVENT1 => { /* ... */ }
    EVENT2 => { /* ... */ }
    EVENT3 => { /* ... */ }
    _ => { /* unknown event */ }
}

これは、人々が共用体を使用して記述できる、または記述できる完全に有効なコードです。

@petrochenkov

このコードは1）ユニオンに対して2）非ユニオンに対して機能する必要がありますか？
私にとって、答えはどちらの場合も明らかな「いいえ」です。これは、Tの「結合」性に関係なく、Rustが防止でき、防止したいエラーのクラス全体だからです。

私にとっては大丈夫です。

ユニオンの最も単純なスキームは、「構造体と同じルール+フィールドの（非）初期化/借用もその兄弟フィールドの（非）初期化/借用」です。

うわー。 構造体ルールは、異なるフィールドが互いに素であるという事実にすべて基づいているため、意味

1）初期化チェックが有効で、2）安全でないコードがユニオンに属する領域に任意の無効なバイトを書き込まない場合、ユニオンの「リーフ」フィールドの1つが自動的に有効になります。 これは動的にチェックできません（少なくともフィールドが1を超え、const-evaluatorの外部にあるユニオンの場合）保証ですが、まずコードを読む人を対象としています。

基本的な妥当性の仮定が動的にチェック可能であることが非常に望ましいと思います（タイプ情報が与えられた場合）。 次に、ミリでのCTFE中にそれらをチェックできます。また、「フル」ミリ実行（テストスイートなど）中にもチェックできます。最終的には、ある種の消毒剤や、Rustがdebug_assert!放出するモードを使用できます。重要な場所で妥当性の不変量をチェックします。
Cのチェックできないルールの経験は、これらが問題であるという十分な証拠を与えていると思います。 通常、ルールが何であるかを実際に理解して明確にするための最初のステップは、動的にチェック可能なルールを表現する方法を見つけることです。 並行性メモリモデルの場合でも、「動的にチェック可能な」バリアント（仮想マシンの段階的な実行に関してすべてを説明する操作的セマンティクス）が現れており、公理の長年の未解決の問題を解決する唯一の方法のようです。以前に使用されたモデル（「薄い空気の問題のouf」はここでのキーワードです）。

動的にチェック可能なルールを持つことがいかに重要であるかを誇張することはできません。 UBのチェックできないケースを0にすることを目指すべきだと思います。 （私たちはまだそこにいませんが、それが私たちが持つべき目標です。）それがあなたの言語でUBを使用する唯一の責任ある方法です。他のすべてはコンパイラ/言語の作者の場合であり、すべての人を犠牲にして彼らの生活を楽にします。結果と一緒に暮らす必要があります。 （私は現在、エイリアシングと生のポインターアクセスのために動的にチェック可能なルールに取り組んでいます。）
それが唯一の問題であるとしても、私に関する限り、「動的にチェックできない」ことは、このアプローチを使用しないための十分な理由です。

とはいえ、これをチェックできない基本的な理由はわかりません。ユニオン内のすべてのバイトについて、すべてのバリアントを調べて、このバリアントでそのバイトに許可されている値を確認し、すべてのユニオン（heh;））を取得します。それらのセットの。 この定義に従ってすべてのバイトが有効である場合、バイトのシーケンスはユニオンに対して有効です。
ただし、これを実際にチェックするのは非常に困難です。これは、Rustで使用する最も複雑な基本的な型の妥当性の不変条件です。 これは、この有効性ルールを説明するのがやや難しいという事実の直接的な結果です。そのため、私はそれが好きではありません。

もちろん、基本的な静的初期化チェックを維持することはできますが、2番目の条件を拒否し、インスタントUBでなくても、安全でない「サードパーティ」手段を介して任意の無効な可能性のあるデータをユニオンに書き込むことができます。 そうすれば、そのダイナミックな人々をターゲットにした保証はもうありません。それは純損失になると思います。

その保証は私たちを買うのですか？ それは実際にどこで役立ちますか？ 今、私が見ているのは、誰もが一生懸命働き、それを守るように注意しなければならないということだけです。 私たち、人々がそれから得られる利益はわかりません。

@joshtriplett

将来、より多くのタグで明示的に拡張可能なCスタイルのタグ付き共用体を検討してください。 ユニオンが考えられるすべてのフィールドタイプを知っていると想定してはならないことを読み取るCおよびRustコード。

@petrochenkovによって提案されたモデルは、 __non_exhaustive: ()フィールドをユニオンに追加することにより、これらのユースケースを可能にします。 しかし、それは必要ではないと思います。 おそらく、バインディングジェネレータはそのようなフィールドを追加することができます。

@RalfJung

これは動的にチェックできません（少なくともフィールドが1を超え、const-evaluatorの外部にあるユニオンの場合）保証

基本的な妥当性の仮定が動的にチェック可能であることが非常に望ましいと思います

明確化：「デフォルト」/「リリースモード」ではチェックできないことを意味しました。もちろん、いくつかの追加のインストルメンテーションを使用して「スローモード」でチェックできることもありますが、これについては私よりもよく書いています。

@RalfJung

@petrochenkovによって提案されたモデルは、ユニオンに__non_exhaustive :(）フィールドを追加することにより、これらのユース

はい、それが提案だと理解しました。

しかし、それは必要ではないと思います。 おそらく、バインディングジェネレータはそのようなフィールドを追加することができます。

可能ですが、すべての組合に体系的に追加する必要があります。

ユニオンの主要なユースケースを破って、含めることができるビットパターンの制限に依存する不特定のユースケースを支持することが理にかなっている理由については、まだ議論がありません。

@joshtriplett

組合の主なユースケース

これが主なユースケースである理由は、私にはまったくわかりません。
タグ付き共用体の共用体のすべての使用/ FFIの「Rustenumエミュレーション」が拡張性を前提としていると仮定すると、 repr(C)共用体に当てはまる可能性があります（これは真実ではありません）が、私が見たところ、 repr(Rust)共用体（ドロップ制御、初期化制御、トランスミュート）は、「予期しないバリアント」が突然出現することを期待していません。

@petrochenkov私は、「主なユースケースを壊す」と言っていなかった、私は、「主なユースケースを壊す」と述べました。 FFIは、組合の主なユースケースの1つです。

そして、それらすべてのセットの結合（heh;））を取ります

「ユニオンの可能な値は、すべての可能なバリアントの可能な値のユニオンである」というステートメントには、確かに魅力的な明白さがあります。

本当。 しかし、それは提案ではありません-私たちは皆、以下が合法であるべきであることに同意します：

union F {
  x: (u8, bool),
  y: (bool, u8),
}
fn foo() -> F {
  let mut f = F { x: (5, false) };
  unsafe { f.y.1 = 17; }
  f
}

実際、これにはunsafeも必要なのはバグだと思います。

したがって、ユニオンは少なくともバイト単位で取得する必要があります。
また、「魅力的な自明性」だけでは十分な理由ではないと思います。 私たちが決定する不変条件は、安全でないコード作成者にとって大きな負担です。その結果、具体的な利点が得られるはずです。

@RalfJung

実はこれが安全でないことさえ要求するのはバグだと思います。

新しいMIRベースの安全性チェッカーの実装についてはわかりませんが、古いHIRベースの実装では、確かにチェッカーの制限/簡略化expr1.field = expr2形式の式のみが可能な「フィールド」について分析されました。割り当て」の安全性のオプトアウト、その他すべては、組合にとって安全ではない一般的な「フィールドアクセス」として保守的に扱われました。

https://github.com/rust-lang/rust/issues/52786#issuecomment -408645420のコメントに答える：

つまり、コンパイラはまだWrap<T>のコントラクトについて何も知らず、たとえばレイアウトの最適化を行うことができないという考えです。 わかりました、この位置は理解されています。
これは、内部的に、 Wrapのモジュール内で、 Wrap<T>モジュールの実装が、たとえば、ユーザーにリークしない場合、一時的に「予期しない値」を書き込むことができることを意味します。コンパイラはそれらで大丈夫です。

予期しない値がないことに関するWrapの契約の一部が、フィールドのプライバシーにどの程度正確に関連しているかはわかりません。

まず、フィールドがプライベートかパブリックかに関係なく、予期しない値をこれらのフィールドから直接書き込むことはできません。 それを行うには、生のポインター、またはFFIの反対側のコードのようなものが必要です。これは、ユニオン全体へのポインターを持つだけで、フィールドアクセスなしで実行できます。 したがって、制限されているフィールドへのアクセス以外の方向からこれにアプローチする必要があります。

私があなたのコメントを解釈するとき、アプローチは、プライベートフィールド（ユニオンまたは構造体では関係ありません）はユーザーに未知の任意の不変条件を意味するので、そのフィールドを（直接またはワイルドポインタを介して）変更する操作はありません問題）は、その不特定の不変条件を壊す可能性があるため、UBになります。

これは、ユニオンに1つのプライベートフィールドがある場合、その実装者（コンパイラではない）は、サードパーティがそのユニオンに予期しない値を書き込むことはないと想定できることを意味します。
これは、ある意味でユーザーにとっての「デフォルトのユニオンドキュメント句」です。
-（デフォルト）ユニオンにプライベートフィールドがある場合、ガベージを書き込むことはできません。
-それ以外の場合は、ドキュメントで明示的に禁止されていない限り、ガベージをユニオンに書き込むことができます。

一部のユニオンが、予期されるフィールドへのpubアクセスを提供しながら、予期しない値を禁止したい場合（たとえば、これらのフィールドに独自の不変条件がない場合）、ドキュメントを介してそれを行うことができます。 2番目の句が必要です。

@RalfJung
これはあなたの位置を正確に説明していますか？

このようなシナリオはどのように扱われますか？

mod m {
    union MyPrivateUnion { /* private fields */ }
    extern {
        fn my_private_ffi_function() -> MyPrivateUnion; // Can return garbage (?)
    }
}

私があなたのコメントを解釈するとき、アプローチは、プライベートフィールド（ユニオンまたは構造体では関係ありません）はユーザーに未知の任意の不変条件を意味するので、そのフィールドを（直接またはワイルドポインタを介して）変更する操作はありません問題）は、その不特定の不変条件を壊す可能性があるため、UBになります。

いいえ、それは私が意図したことではありません。

複数の不変条件があります。 必要な数はわかりませんが、少なくとも2つは必要です（そして、それらの名前はわかりません）。

• 型の「レイアウトレベルの不変」（または「構文の不変」）は、型の構文の形によって完全に定義されます。 これらは、「 &mut TはNULLではなく、整列されている」、「 boolは0または1 」、「 !はできません」などです。存在する」。 このレベルでは、 *mut Tはusizeと同じです。どちらも任意の値（または初期化された値）を許可しますが、その区別は別の説明のためです。 最終的には、構造体の再帰によって、すべてのタイプのこれらの不変条件を詳しく説明するドキュメントを作成する予定です。構造体のレイアウトレベルの不変条件は、すべてのフィールドの不変条件が維持されることなどです。ここでは、可視性は役割を果たしません。

Violating the layout-level invariant is instantaneous UB. This is a statement we can make because we have defined this invariant in very simple terms, and we make it part of the definition of the language itself. We can then exploit this UB (and we already do), e.g. to perform enum layout optimizations.

• タイプの「カスタムタイプレベル不変条件」（または「セマンティック不変条件」）は、そのタイプを実装する人によって選択されます。 コンパイラは、それを表現する言語がないため、この不変条件を知ることができません。言語定義についても同じことが言えます。 この不変条件が何であるかさえ言えないので、この不変条件UBに違反することはできません。 カスタム不変条件を持つことさえ可能であるという事実は、あらゆる有用な型システムの特徴です：抽象化。 これについては、過去のブログ投稿で詳しく書いています。

  カスタムのセマンティックインバリアントとUBの関係は、安全でないコードが、外部コードによって保持されているセマンティックインバリアントに依存している可能性があることを宣言することVecのサイズフィールドにランダムなものを入れるだけでは正しくありません。 私が間違っていると言ったことに注意してください（私は時々 unsoundという用語を使用します）-しかし未定義の動作ではありませ&mut ZSTエイリアシングルールに関する説明です。 ぶら下がっている適切に配置されたnull以外の&mut ZST作成することは、すぐにUBになることはありませんが、これが起こらないことに依存する安全でないコードを書く可能性があるため、それでも正しくない/正しくありません。

これら2つの概念を一致させるのは良いことですが、実用的ではないと思います。 まず、一部のタイプ（関数ポインター、dyn特性）では、カスタムのセマンティック不変条件の定義は、実際には言語でのUBの定義を

予期しない値がないことについてWraps契約の一部がどの程度正確にフィールドのプライバシーに関連しているかはわかりませんが、

基本的に、型がそのカスタム不変条件を選択するとき、安全なコードが実行できるすべてのものが不変条件を保持することを確認する必要

たとえば、構造体のパブリックフィールドは、フィールドタイプのカスタム不変条件とは異なるカスタム不変条件を持つことはできません。結局のところ、安全なユーザーは、そのフィールドに任意のデータを書き込んだり、フィールドから読み取って「良好」を期待したりできます。データ。 すべてのフィールドが公開されている構造体は安全に構築でき、フィールドにさらに制限を課します。

パブリックフィールドとの結合...まあ、それはやや興味深いです。 ユニオンフィールドの読み取りはとにかく安全ではないので、そこでは何も変わりません。 ユニオンフィールドの記述は安全であるため、パブリックフィールドを持つユニオンは、フィールドに入力されるそのフィールドの型のカスタム不変条件を満たす任意のデータを処理できる必要があります。 これが非常に役立つとは思えません...

したがって、要約すると、カスタム不変条件を選択するときは、外部の安全なコードがこの不変条件を壊さないようにするのはあなたの責任です（そして、これを達成するのに役立つプライベートフィールドのようなツールがあります）。 そのコードが安全なコードができないことをするとき、あなたの不変条件に違反しないことは外国のunafeコードの責任です。

これは、内部的に、Wrapのモジュール内で、Wrapの実装を意味しますたとえば、モジュールは、ユーザーにリークしない場合、一時的に「予期しない値」を書き込むことができ、コンパイラはそれらに問題がありません。

正しい。 （ここではパニックの安全性が懸念事項ですが、おそらくご存知でしょう）。 これは、 Vec 、安全に実行できるのと同じです。

let sz = self.size;
self.size = 1337;
self.size = sz;

UBはありません。

mod m {
    union MyPrivateUnion { /* private fields */ }
    extern {
        fn my_private_ffi_function() -> MyPrivateUnion; // Can return garbage (?)
    }
}

構文レイアウトの不変条件に関して、 my_private_ffi_functionは何でも実行できます（関数呼び出しABIと署名が一致すると仮定）。 セマンティックカスタム不変条件に関しては、コードには表示されません-このモジュールを作成した人は誰でも不変条件を念頭に置いていたので、ユニオン定義の横にそれを文書化してから、FFI関数が不変条件を満たす値を返すことを確認する必要があります。

私はついに、 &mut T初期化する必要があるかどうか、いつ初期化する必要があるか、および上記の2種類の不変条件についてのブログ投稿を書きました。

https://github.com/rust-lang/rust/issues/55149でまだカバーされていない、ここで追跡するものが残ってい

E0658はまだここを指しています：

エラー[E0658]： Copyフィールドを持つユニオンは不安定です（問題＃32836を参照）

彼らはCopy実装していないので、これは現在アトミックでひどく遊んでいます。 誰かが回避策を知っていますか？

https://github.com/rust-lang/rust/issues/55149が実装されている場合、ユニオンでManuallyDrop<AtomicFoo>を使用できるようになります。 それまでは、回避策はNightlyを使用することです（またはunionを使用せずに別の方法を見つけてください）。

これを実装すれば、 ManuallyDropも必要ありません。 結局のところ、rustcはAtomic*がDrop実装していないことを知っています。

追跡の問題を新しい問題に切り替えるように自分を割り当てます。