スタックの固定はRFCの一部ではないことに気付きました。 @ withoutboatsはこのためのクレートをリリースする予定それともサンプルコードをそれを必要とするクレートにコピーする必要がありますか？

@ Nemo157あなたはそれをコピーして、あなたの経験を報告するべきです！

Unpinデータの漏洩に関する未解決の質問は、これに関連しています。 @cramertjが要求したように、デストラクタが実行されない限り、 Pin内のUnpinデータを上書きできないと言えば、そのAPIは適切ではあり

私が注意することの1つは、スタックの固定は、ループでポーリングすることができなかったため、 await!マクロ内のFuture::pollようなものには十分ではなかったことです。 あなたがそれらの問題に遭遇したかどうか、そしてあなたがそうしたらどのように/あなたがそれらを解決するかどうか私は興味があります。

私の現在の使用法は非常に簡単で、サポートを生成せずに単一のStableFutureを実行するシングルスレッドのエグゼキュータです。 @cramertjのようなAPIに切り替えると、これで問題ことがStableFuture生成できるようにする方法を考えましたが、少なくとも現在のプロジェクトでは必要ありません。

APIを試してみました。 次の（RFCで提案されている） Future定義は、オブジェクトセーフではなくなったように見えますか？

trait Future {
    type Item;
    type Error;

    fn poll(self: Pin<Self>, cx: &mut task::Context) -> Poll<Self::Item, Self::Error>;
}

気にしないで。 arbitrary_self_typesオブジェクトセーフにする計画についてのメモを見つけました。

@withoutboats

私が注意することの1つは、スタックの固定が、Future :: poll in await！のようなものには十分ではなかったことです。 マクロ。ループでポーリングすることができなかったためです。

それについて詳しく教えていただけますか？

@RalfJung Pinとしての再借入をサポートするには、 Pinが必要ですが、現在はサポートしていません。

@cramertjこれは、スタック固定APIではなく、 Pin APIの制限のように聞こえますか？

@RalfJungはい、その通りです。 ただし、 PinBoxはPinとして再借用できますが、スタック固定タイプは再借用できません（ Pinとして1回借用すると、スタックタイプの存続期間全体にわたって借用が作成されます）。

与えられたPin 、私のようにそれを借りることができます&mut Pin使用し、その後およびPin::borrow reborrowingの形だと- 。 私はあなたが話している種類のreborowingではないと思いますか？

@RalfJungいいえFuture::pollようなメソッドは、 self: &mut Pin<Self>ではなくself: Pin<Self>を取るように計画されていました（これは有効なselfタイプではないため ' t Deref<item = Self> - Deref<Item = Pin<Self>> ）。

これを実際にPin::borrowさせることができる場合があります。 よく分かりません。

@cramertj x: &mut Pin<Self> pollを呼び出すことを提案しませんx: &mut Pin<Self> ; x.borrow().poll()を考えました。

@RalfJungああ、なるほど。 はい、手動で再借用する方法を使用すると機能する可能性があります。

これは少し厄介ですが、この動作の例です。

再借用が完全に機能していることがわかる限り、来週Pin行っている作業の例を投稿することを忘れないでください。 futures::io::AsyncReadトレイトの固定バージョンと、 fn read_exact<'a, 'b, R: PinRead + 'a>(read: Pin<'a, R>, buf: &'b [u8]) -> impl StableFuture + 'a + 'bような動作するアダプターがあり、これを比較的複雑なStableFuture変換して、上部にスタック固定することができます。レベル。

これが私が読んでいるものの完全な例です：

pub trait Read {
    type Error;

    fn poll_read(
        self: Pin<Self>,
        cx: &mut task::Context,
        buf: &mut [u8],
    ) -> Poll<usize, Self::Error>;
}

pub fn read_exact<'a, 'b: 'a, R: Read + 'a>(
    mut this: Pin<'a, R>,
    buf: &'b mut [u8],
) -> impl StableFuture<Item = (), Error = Error<R::Error>>
         + Captures<'a>
         + Captures<'b> {
    async_block_pinned! {
        let mut position = 0;
        while position < buf.len() {
            let amount = await!(poll_fn(|cx| {
                Pin::borrow(&mut this).poll_read(cx, &mut buf[position..])
            }))?;
            position += amount;
            if amount == 0 {
                Err(Error::UnexpectedEof)?;
            }
        }
        Ok(())
    }
}

インスタンスをPinとしてどこにでも渡し、それらの関数を呼び出すたびにPin::borrowを使用する必要があるため、これは少し面倒です。

#[async]
fn foo<'a, R>(source: Pin<'a, R>) -> Result<!, Error> where R: Read + 'a {
    loop {
        let mut buffer = [0; 8];
        await!(read_exact(Pin::borrow(&mut source), &mut buffer[..]));
        // do something with buffer
    }
}

値をPin<'a, R>どこにでも渡さなければならないことを回避するには、 impl<'a, R> Read for Pin<'a R> where R: Read + 'aを使用できると思っていましたが、代わりにfn foo<R>(source: R) where R: Read + Unpin使用できました。 残念ながら、 Pin<'a, R>: !Unpinが原因で失敗します。ピン自体は単なる参照であり、その背後にあるデータはまだ固定されているため、 unsafe impl<'a, T> Unpin for Pin<'a, T> {}を追加しても安全だと思います。

懸念事項：型パラメーターがPinなくても、libstdのほとんどの型にUnpin無条件に実装してほしいと思われます。 例としては、 Vec 、 VecDeque 、 Box 、 Cell 、 RefCell 、 Mutex 、 RwLock 、 Rc 、 Arc 。 ほとんどのクレートはピン留めについてまったく考えないので、すべてのフィールドがUnpin場合、タイプはUnpinなると思います。 これは適切な選択ですが、インターフェイスが不必要に弱くなります。

すべてのlibstdポインタータイプ（おそらくrawポインターを含む）とUnsafeCell Unpinを実装することを確認した場合、これは自動的に解決しますか？ それは私たちがやりたいことですか？

すべてのlibstdポインタータイプ（おそらくrawポインターを含む）とUnsafeCellにUnpinを実装することを確認した場合、これは自動的に解決しますか？ それは私たちがやりたいことですか？

はい、私にはSendと同じ状況のようです。

新しい質問がちょうど私に起こりました： PinとPinBox Sendですか？ 今、自動車形質メカニズムがそれらを作るSendたびTあるSend 。 それを行う先験的な理由はありません。 共有型状態の型が送信可能性のための独自のマーカー特性（ Syncと呼ばれる）を持っているのと同じように、 Pin<T>がSend場合、たとえばPinSendようにマーカー特性を作成できます。 Sendが、 PinSendはない型を書くことは可能であり、その逆も可能です。

@RalfJung Pinは、 &mut Tが送信の場合に送信されます。 PinBoxが送信の場合、 Box<T>は送信です。 それらが異なる理由は見当たらない。

さて、いくつかのタイプがSendが、 Syncではないのと同じように、「このメソッドがPin<Self>で呼び出されると、移動されないことを信頼できます。別のスレッドに」。 たとえば、これにより、最初に開始する前に送信できる先物が発生する可能性がありますが、その後は1つのスレッドにとどまる必要があります（開始する前に移動できるが、固定されたままにする必要があるのと同じです）。 説得力のある例を思い付くことができるかどうかはわかりません。スレッドローカルストレージを使用する将来について何か考えられるでしょうか。

@Diggseyが言及した生涯の問題にぶつかっPin<Option<T>> -> Option<Pin<T>>は安全な操作であるはずですが、この安全なコードを作成するために必要なAPIの種類は言うまでもなく、現在の安全でないAPIを使用しても実装できないようです。

trait OptionAsPin<T> {
    fn as_pin<'a>(self: Pin<'a, Self>) -> Option<Pin<'a, T>>;
}

impl<T> OptionAsPin<T> for Option<T> {
    fn as_pin<'a>(self: Pin<'a, Self>) -> Option<Pin<'a, T>> {
        match *unsafe { Pin::get_mut(&mut self) } {
            Some(ref mut item) => Some(unsafe { Pin::new_unchecked(item) }),
            None => None,
        }
    }
}

（トランスミュートを使用してライフタイムを強制することを回避することは可能ですが、それは私を非常に不快に感じさせます）。

未解決の質問を追加したい：共有の固定参照型を追加し直す必要がありますか？ 答えはイエスだと思います。 詳細については、この投稿とディスカッションを参照してください。

私だけのことを読んで、私はそれが思ったよう先物0.2が最終的なようではありませんので、多分それは名前を変更するために、すべての後にまだ可能である、 PinバックにPinMutと共有バージョンを追加します。

@RalfJungあなたが提案する変更を理解するために、私はあなたのブログ投稿をもう一度

不変のPinバリアントを持つための潜在的に説得力のあるユースケースを見つけたと思いますが、 Derefと&Pin<T> <=> &&Tについてのあなたのコメントを理解していません。 Pin<T>を安全に&Tにキャストできたとしても、 &TをPin<T>キャストできないため、同等にはなりません。 安全な変換を安全でないものにする理由がわかりません（安全なDeref implを削除することによって）。

現在、 mapのメソッドPin署名を持っています

pub unsafe fn map<U, F>(this: &'b mut Pin<'a, T>, f: F) -> Pin<'b, U>

以下ではない理由は何ですか？

pub unsafe fn map<U, F>(this: Pin<'a, T>, f: F) -> Pin<'a, U>

現状では、あるタイプのPinをそのフィールドの1つのPinに変換するには、ライフタイムを不必要に短くする必要があります。

mapメソッドのもう1つの問題は、構造体のPinを、それぞれが構造体の異なるフィールドである2つのPinに変換できないように見えることです。 それを達成するための正しい方法は何ですか？

私はそのためにこのマクロを使用しています：

macro_rules! pin_fields {
    ($pin:expr, ($($field:ident),+ $(,)?)) => {
        unsafe {
            let s = Pin::get_mut(&mut $pin);
            ($(Pin::new_unchecked(&mut s.$field),)+)
        }
    };
}

Pinに関する多くの議論では、ピンをプライベートフィールドに「投影」することは安全であると考えられるべきであるという仮定があるようです。 私はそれがまったく真実ではないと思います。 たとえば、 mapに関するドキュメントコメントは現在次のようになっています。

引数値が移動しない限り（たとえば、その値のフィールドの1つであるため）、返されるデータが移動しないこと、および受け取った引数から移動しないことを保証する必要があります。インテリア機能。

「引数値が移動しない限り、返されるデータは移動しない」という保証は、 map呼び出し元が守らなければならないコントラクトの正しい説明です。 括弧で囲まれた「（たとえば、その値のフィールドの1つであるため）」は、自分のプライベートフィールドへの参照を返すだけで、安全であることが保証されていることを意味しているようです。 しかし、 Dropを実装する場合、それは真実ではありません。 Drop implは、他のコードがすでにPin<Self>認識している場合でも、 &mut self Drop認識します。 mem::replaceまたはmem::swapを使用してフィールドから移動し、以前のmap 「正しい」使用による約束に違反する可能性があります。

言い換えると、 Pin::mapへの「正しいピンプロジェクション」呼び出し（呼び出しはunsafe { Pin::map(&mut self, |x| &mut x.p) }ように見えます）を使用し、他にunsafe呼び出さない場合、不健全/未定義を生成できます。動作。 これを示す遊び場のリンクは次のとおりです。

これは、現在のAPIに問題があることを意味するものではありません。 これは、 Pin::mapをunsafeとしてマークする必要があることを示していますが、これはすでにマークされています。 また、先物などを実装するときに、人々が誤ってこれにつまずく危険性はあまりないと思います。 Drop implで自分のフィールドから移動するには、本当に邪魔にならないようにする必要があります。私はそれをやりたいと思う多くの実際的な理由があるとは思えません。

しかし、 mapのドキュメントコメントでこれについて言及したいと思うかもしれません。また、RFCとその周辺の議論で見られる拡張機能のアイデアが無効になると思います。

• 「ピンプロジェクション」を実行し、安全に見えるようにするマクロ/派生物があってはなりません。 プロジェクションは実際には、それを取り巻く他のコードにコントラクトを課しますが、コンパイラーはそれを完全に強制することはできません。 したがって、完了するたびにunsafeキーワードを使用する必要があります。
• RFCは、 Pinが&'a pin T言語機能に変換された場合、「フィールドを介して投影するのは簡単」であると述べています。 プライベートフィールドの投影に限定されている場合でも、これにはunsafeが必要であることを示したと思います。

@withoutboats

ピンでも＆Tをピンにキャストできないため、安全に＆Tにキャストできますが、同等にはなりません。。

確かに、それは十分条件ではありません。 以前の投稿で次の定義を行ったため

定義5： PinBox<T>.shr 。 ポインタptrとライフタイム 'aは、ptrがT.shr('a, inner_ptr)ような別のポインタinner_ptrへの読み取り専用ポインタである場合、 PinBox<T>の共有型状態を満たします。

（そして、一種の暗黙のうちに、 Pin<'a, T>.shrの対応する定義。）
PinBox<T>.shrがT.shrだけに依存していることに注目してください。 これは作るPinBox<T>.shrとまったく同じ不変のBox<T>.shrことを意味する、 &Box<T> = &PinBox<T> 。 同様の推論は、 &&T = &Pin<T>ことを示しています。

したがって、これはRFCに記述されたAPIまたは契約の結果ではありません。 これは、所有、共有、固定の3つのタイプ状態を持つモデルの結果です。 &&T = &Pin<T>に反対する場合は、4番目のタイプステートである「共有ピン留め」の導入について議論する必要があります。

@MicahChalmer

ピンに関する多くの議論では、ピンをプライベートフィールドに「投影」することは安全であると考えられるべきであるという仮定があるようです。 私はそれがまったく真実ではないと思います。

それはとても良い点です！ ただ、明確にするために、作る際の問題はないpのフィールドShenanigans国民は、ありますか？ その時点で、どのクライアントもdo_something_that_needs_pinning書き込むことができ、RFCの目的はそれを安全にすることです。 （RFCがプライベートフィールドに具体的に言及している理由はわかりません。私の解釈では、すべてのフィールドで機能するはずでした。）

これが私のモデルのdropのdrop(ptr)はT.pin(ptr)前提条件があると書きました。 この解釈では、例で実際に問題となっているコードはdrop実装になります。 （投稿を書いているときになぜこれに気づかなかったのか疑問に思います...）最終的にはフィールドへの安全な投影を許可したいと思います。 dropに&mut提供するべきではありません。タイプがピン留めを行う場合は

（a）タイプが!Unpin場合はimpl Drop安全でなくする方法、または（b） T: !Unpin場合drop(self: Pin<Self>)変更する方法はありますか？ ？ どちらも非常に遠慮がちに聞こえますが、一方で、フィールドプロジェクションの安全性を維持しながら、 Drop::dropを変更して常にPin<Self>取ることができる場合;）しかしもちろん、現時点では、これはライブラリのみのソリューションではありません。 悲しい部分は、そのまま安定させた場合、安全なフィールド予測を行うことができないということです。

@RalfJungだから、私は実際的な質問にもっと興味があります（おそらく：wink：を期待するでしょう）。 私は2つあると思います：

• Pin<T: !Unpin>はDeref<Target =T>実装する必要がありますか？
• Pin<T>とPinMut<T> （前者は共有ピン）の両方が必要ですか？

最初の質問に否定的に答える理由はわかりません。 2番目の質問を再開したと思います。 私は2つの異なる種類のピンに戻る傾向があります（しかし完全には確信していません）。 これを言語レベルの参照型にアップグレードすると、 &pin Tと&pin mut Tます。

何をしても、APIの不変条件を正確に反映するには、モデルに4番目の型状態が必要になるようです。 &&Tを&Pin<T>変換するのは安全ではないと思います。

だから私は実際的な質問にもっと興味があります（おそらくウィンクを期待するでしょう）。

けっこうだ。 ;）ただし、安全でないコードが登場した後は、 Pin前後で何が保証され、何が保証されないかについて、少なくとも基本的な理解を持っていることが重要だと思います。 Basic Rustはこれを理解するために数年の安定化を持っていましたが、今では数か月でPinこれを繰り返しています。 Pinは、構文に関する限りライブラリのみの追加ですが、モデルに関する限り重要な追加です。 安全でないコードとは何かを可能な限り徹底的に文書化し、 Pinを想定したり実行したりすることは許可されていないことが賢明だと思います。

これらの懸念は現在理論的なものですが、安全でないコードが互換性のない仮定をしているために最初の不健全さが発生すると、突然非常に実用的になります。

2番目の質問について：

何をしても、APIの不変条件を正確に反映するには、モデルに4番目の型状態が必要になるようです。 && Tを＆Pinに変換するとは思わない安全なはずです。

それが私が期待したことです。

保守的にしたい場合は、 Pin名前をPinMutできますが、 PinShr追加することはできません（ Pinと呼ばれる可能性がありますが、ここで明確にしようとしています）今のところ、安全でないコードが仮定できることを宣言&PinMut<T>実際にピン留め何かを指します。 次に、後で共有の固定参照としてPinを追加するオプションがあります。

PinShrを使用する実際的な理由は、 @ comexによって提起されPinShr<'a, Struct>からPinShr<'a, Field>までのゲッターを提供できるはずです。 動作しない共有ピンに&PinMutを使用する場合。 そのようなゲッターがどれだけ必要になるかはわかりません。

最初の質問については、いくつかの強力な議論があるようです：（a）オブジェクトセーフな任意の自己タイプの現在の計画、および（b）共有参照で既存のAPIを大量に安全に使用できることPinShr （またはPinMut ）。

&mutとPinMut両方で機能する操作を同様に提供する簡単な方法がないように思われるのは残念です。 結局のところ、 &mut動作する多くのコードは、 mem::swapを使用する意図はありません。 （これは、私が見ているように、 !DynSizedベースのソリューションまたは同等のものの主な利点です。 &mutは、固定される場合とされない場合がある参照の型になります。これをPin APIのさらに別のライブラリタイプとして持つこともできますが、これらすべての&mutメソッドがすでに存在することを考えると、それはかなり無意味です。）

&TとPinMut<T>両方に対して「興味深い」ことをしたいタイプである、反対の軽い議論が1つあります。 それを行うのは難しいでしょう、すべてが可能であるというわけではなく、そして人は非常に注意しなければなりません。 しかし、それが良い議論に勝るとは思わない。

この場合（つまり、このimpl Deref ）、 PinShr<'a, T>は、それを&'a Tに変換する（寿命を維持する）安全なメソッドが付属している必要があります。

そして、私たちが解決しなければならないと思う別の懸念があります。 @ MicahChalmerが上記で気づいたことに照らして、 Pin::mapおよび/またはdropルールです。 2つの選択肢があります。

• Pin::mapをパブリックフィールドへの射影とともに使用すること（derefなし、暗黙的でさえない）は常に安全であることを宣言します。 これは現在のRFCの私の解釈です。 これは&mutと&一致します。 ただし、 Drop周りに問題があります。それ以外の場合は整形式の!Unpinタイプが与えられると、UBを引き起こす安全なコードを記述できるようになりました。
• Drop周りで面白いことは何もしないでください。 次に、 Pin::map大きな警告を追加する必要があります。これをパブリックフィールドに使用しても、不健全になる可能性があります。 &pin Tとしても、それを使用して安全なコードのフィールドにアクセスすることはできません。

私が見ることができる2番目のオプションの唯一の可能な議論は、それが私たちが実際に実装できる唯一のものであるかもしれないということです。 ;）あらゆる点で劣っていると思います。 &pinは、ある日組み込まれたとしても、かなり奇妙で非人間的なものになります。これはフットガンであり、構成性を妨げます。

そこ最初のオプションを達成するための方法であるが、それは簡単ではないだと私は後方互換性、それを作るための方法が分からないことがあります。私たちは、追加することができますUnpinにバインドDrop 、そして追加DropPinnedには境界がなく、 dropはPin<Self>取ります。 UnpinバインドされたDropは、 impl Drop for Sを記述できる奇妙な方法で強制される可能性がありますが、これにより、 S暗黙のバインドが追加されます。 Unpinます。 おそらく現実的ではありません。 ：/（これは、 !DynSizedベースのアプローチがより効果的に機能するポイントでもあると思います。 &mut Tを「固定される場合とされない場合」に変換し、 drop維持します。音。）

@RalfJung @MicahChalmer Drop implのフィールドから移動した場合、そのフィールドのピンに他の場所に投影するのは適切ではないことを文書化する方がよいと思います。

実際、（安全でないコードを使用して） !Unpinタイプのフィールドから移動できるというのは、今日すでに事実です。これは、他の場所でそのフィールドのピンに投影しない限り、安全で明確に定義されています。 。 Dropとの唯一の違いは、移動部分には安全なコードしか含まれていないことです。 Pin::mapメモは、Drop implに関係なく、そのフィールドから移動した場合は安全では

場合によっては、 !Unpinタイプのフィールドから移動しても安全である必要があります。これは、ジェネレータが戻ったときに、フィールドの1つから移動する可能性が非常に高いためです。

Drop implでフィールドの外に移動した場合、そのフィールドのピンに他の場所に投影するのは適切ではないことを文書化する方がよいと思います。

これは2番目のオプションであり、フィールドへの&pinを永続的に安全でない操作にします。
これは小さな変化ではないと思います。 これにより、フィールドのpub意味が根本的に変わります。 ライブラリタイプを使用する場合、そのドロップimplで何が行われるのかわからないため、基本的に、そのフィールドへの固定参照を取得する方法がありません。

たとえば、 OptionがDrop何かをすることは絶対にないと明示的に述べていない限り、 Pin<Option<T>>からOption<Pin<T>>に移動することさえ許可されません。おかしい」。 コンパイラはそのステートメントを理解できないため、 Optionはこれを行うための適切な方法を提供できますが、 match同じことを行うと、安全でない操作のままにする必要があります。

ドロップとの唯一の違いは、移動部分には安全なコードしか含まれていないことです。

しかし、それは大きな違いですよね？ 安全でないコードが実行できるかどうかについて任意のルールを設定できますが、安全なコードについてはそうではありません。

ジェネレータが戻ったときにフィールドの1つから移動する可能性が非常に高いため、場合によっては、！Unpinタイプのフィールドから移動しても安全である必要があります。

この場合、フィールドはUnpin思いますか？ したがって、外部構造体のパブリックフィールドのPin::mutは、そのフィールドのタイプがUnpinあれば、問題ないというルールがあります。 これがどれほど役立つかはわかりませんが、おそらく何もないよりはましです。

&&Tよりも多くの保証を提供しない&Pin<T>についての混乱をすぐに言い直したいと思います。 & 、 &mut 、および&pinそれぞれ「共有アクセス」、「一意のアクセス」、および「移動されない値への一意のアクセス」を提供します。 &&pinを「移動されないタイプへの一意のアクセスへの共有アクセス」として理解すると、メモリが共有されていることがわかります（ &pinの一意性の保証は、の共有によってキャンセルされます。 & ）、ただし、型が移動されないというプロパティは保持されますね。

あなたが何を求めているのか、何を言っているのかわかりません。 「共有ピン留め」がそれ自体で基本モード/タイプステートであると私が考える理由を混乱させていますか？

重要なのは、「共有アクセス」は私が自分で定義する方法を知っていることではないということです。 Cell 、 RefCell 、 Mutexの非常に異なる方法で見られるように、共有と共有の調整にはさまざまな方法があります。

自分が所有している何かを共有している（何かの「一意性の保証をキャンセルする」）とだけ言って、そのステートメントが意味をなすと期待することはできません。 どのように共有している

「共有ピン留め」を共有とピン留めの直交構成として発生させる方法は考えられません。 「（通常の）共有」と「固定共有」を生み出すために、所有または固定不変条件のいずれかに適用できる「共有メカニズム」の概念を定義する方法があるかもしれませんが、私はそれを真剣に疑っています。 また、 RefCell横ばいになるのを見てきたように、 RefCellが共有ピン不変量に対して、ちょうど共有不変量に対して行うのと同様のことを行う場合、 & &pin RefCell<T>からそれを正当化することはできません。 &RefCell<T> （ Deref ）経由borrow_mutピン留めが発生しなかったことを示す&mut参照を取得できます。

@RalfJung

ドロップにバインドされたUnpinを追加し、バインドがなく、ドロップがピンを取得する場所にDropPinnedを追加することができます。。

Dropの定義は本当にここで問題ですか？ それについて考える別の方法は、 mem::swapとmem::replace責任を負わせることです。 これらは、所有していないものを移動できるようにする操作です。 T: Unpinバウンドが_them_に追加されたとしましょう。

手始めに、それは私が指摘したdrop穴を修正するでしょう-私のShenanigansはコンパイルに失敗し、別のunsafeなしでピンの約束に違反することはできないと思いますdropで以前に固定された値への&mut参照を取得することが安全になった場合、なぜそれをdropだけに制限するのですか？

何かが足りない場合を除いて、これにより、いつでもPinMut<T>から&mut参照を借りても安全だと思います。 （私が使用していますPinMut 、現在では毎晩、いわゆる、を参照するためにPin兼用端子についての議論との混同を避けるために、。） PinMut<T>実装できるDerefMut T: Unpinだけでなく、無条件にDerefMut T: Unpin 。

＆mutとPinMut;の両方で機能する操作を同様に提供する簡単な方法がないように思われるのは残念です。 結局のところ、＆mutで動作する多くのコードは、 mem::swapを使用する意図はありません。

PinMutのDerefMut implはそれを修正しますよね？ 固定を気にし、 PinMutを必要とするコードは、 &mutで機能するコードを安全かつ簡単に呼び出すことができます。 代わりに、 mem::swapを使用したいジェネリック関数に負担がかかります。これらの関数にはUnpinバインドを追加するか、 unsafeを使用して注意する必要があります。ピンの状態に違反しないようにしてください。

このような境界をswapとreplace追加すると、最初の安定版リリースに戻る下位互換性が失われます。 ここからそこにたどり着く現実的な方法がわかりません。 しかし、これが1.0より前の時代に知られていれば、それがやるべきことだったと考えることで、他の穴が欠けているのでしょうか。

現状では、 見当たりません- map安全に保ち、以前にdrop固定されていたフィールドから移動しないように警告するメッセージをドキュメントに入れます

安全でないコードが実行できるかどうかについて任意のルールを設定できますが、安全なコードについてはそうではありません。

unsafeを使用すると、周囲の安全なコードに常にルールが適用されます。 ここでの朗報は、私たちが知る限り、ピン留め可能な構造体にピンをプライベートフィールドに投影するメソッドがある場合、それを使用して安全なコードのコントラクトに違反できるのは、それ自体のdrop implだけです。 したがって、そのようなプロジェクションを追加して、その構造体の_users_に完全に安全なAPIを提示することは可能です。

ドロップの定義は本当にここで問題ですか？

非難の割り当てはやや恣意的であり、健全性の穴を塞ぐために変更できることがいくつかあります。 しかし、私が提案したようにDropを変更すると、問題が解決することに同意しますか？

それについて考える別の方法は、mem :: swapとmem :: replaceに責任を負わせることです。 これらは、所有していないものを移動できるようにする操作です。 T：アンピンバウンドがそれらに追加されたとしましょう。

そうですね、それで&mut Tは!Unpinタイプで一般的に安全に使用できるようになります。 ご存知のように、 PinMutはもう必要ありません。 あなたの提案のPinMut<'a, T>は&'a mut Tとして定義できますよね？
これは基本的に、下位互換性と言語の複雑さの問題のために以前に破棄された?Move提案です。

安全でないものを使用すると、周囲の安全なコードに常にルールが課せられます。

どういう意味かわかりません。 プライバシーの境界を超えて、これは当てはまらないはずです。 安全でないコードは、クライアントに何も課すことはできません。

ここでの朗報は、私たちが知る限り、ピン留め可能な構造体にピンをプライベートフィールドに投影するメソッドがある場合、それを使用して安全なコードのコントラクトに違反できるのは、それ自体のドロップimplだけです。 したがって、そのようなプロジェクションを追加して、その構造体のユーザーに完全に安全なAPIを提示することは可能です。

はい、タイプはプロジェクションが安全であると宣言するためにオプトインできます。 ただし、たとえば、借用チェッカーはこれがフィールドアクセスであることを理解しないため、 PinMut<Struct>が与えられた場合、そのようなメソッドを使用して2つの異なるフィールドに同時にPinMutを取得することはできません。

しかし、私が提案したようにDropを変更すると問題が解決することに同意しますか？

私は同意します、それはそれを修正するでしょう。

PinMutはもう必要ありません。 あなたの提案のPinMut <'a、T>は＆' a mut Tとして定義できますよね？

いいえ、指示対象が二度と移動しないことを約束するには、 PinMut<'a, T>が引き続き必要です。 &'a mut Tを使用すると、生涯'a間移動しないと信頼することしかできません

「さび
構造体X;
impl！X {}の固定を解除します
fn Takes_a_mut_ref（_：＆mut X）{}

fn Borrow_and_move_and_borrow_again（）{
mut x = Xとします。
Takes_a_mut_ref（＆mut x）;
mut b = Box :: new（x）;
Takes_a_mut_ref（＆mut * b）;
}
「」

PinMut<'a, T>から&'a mut Tに移動するのは安全ですが、その逆は安全ではありません。 PinMut::new_uncheckedは引き続き存在し、 unsafeです。

これは基本的に、下位互換性と言語の複雑さの問題のために以前に破棄された?Move提案です。

私が理解しているように、 ?Move提案は、上記のコードスニペットを禁止するように基本的な言語ルールを変更することによって（ Unpin作成することによって）、 PinMut必要としないようにしようとしていUnpinはMove特性になります。）私はそのようなことを提案していません-私の提案は、今夜の状態とまったく同じように開始することです。

• std::mem::swap std::mem::replace関数とUnpinを追加します
• PinのDerefMut implからUnpinバウンドを削除します（名前の変更が発生した場合はPinMut ）

それがすべてです-動きがどのように機能するか、またはそのようなものに基本的な言語の変更はありません。 私の主張は次のとおりです。はい、これは重大な変更になりますが、 Drop変更するよりも重大な影響は少なくなります（これは?Move提案よりも大幅ではありません）。利点の。 特に、安全なピンプロジェクションを可能にし（少なくともプライベートフィールドでは、パブリックでもそうだと思いますか？よくわかりません）、 PinMutと&mut動作するように並列コードを記述しなければならない状況を防ぎます。

いいえ、PinMut <'a、T>は、指示対象が二度と移動しないことを約束する必要があります。 ＆ 'a mut Tを使用すると、一生動かないことだけを信頼できます' a。

そうですか。 理にかなっています。

私が理解しているように、？Moveの提案は、基本的な言語ルールを変更して上記のコードスニペットを禁止することにより（UnpinをMoveトレイトにすることにより）、PinMutを必要としないようにしようとしていました。

理解しました。

私の主張は次のとおりです。はい、これは重大な変更になりますが、Dropを変更するよりも重大な影響は少なくなります。

どの変更をドロップするのですか？ Unpinバウンドを追加しますか？ あなたは正しいかもしれませんが、 mem::swapとmem::replaceがどれほど広く使われているのかわかりません。

特に、それは安全なピンの投影を可能にするでしょう（少なくとも私的なフィールドのために、そして私は公共のためにさえ思う？よくわかりません）

ここでは、プライベートとパブリックがどのように違いを生むことができるのかわかりません。 パブリックフィールドはどのようにしてプライベートフィールドよりも少ないものを許可しますか？

しかし、ええ、これは全体的に一緒になっているようです。 Futureは、決して動かないものに依存する必要があるため、 PinMutが必要ですが、使用できるメソッドの範囲は広くなります。

ただし、互換性の側面は大きなものです。 これは現実的ではないと思います。 mem::swap / mem::replaceを呼び出すすべてのジェネリックコードが壊れてしまいます。 さらに、現在、安全でないコードは、 ptr::read / ptr::writeを使用してこれらのメソッド自体を自由に実装できます。 これにより、既存の安全でないコードがサイレントに破損する可能性があります。 それはダメだと思います。

mem::swapとmem::replaceバインドされたUnpinを導入するというトピックに取り組んでいますが、破損については心配していません。 「コンパイラ組み込み」ルートが採用されていると仮定すると。 mem::forgetに同じ境界を導入して、スタックに固定された変数に対してデストラクタが実行されることを保証し、 thread::scoped鳴らして、特定の場合に「ズボンをうんちする」ことを回避することもできますか？

mem::forget PinBoxはstlllで許可されていることに注意してください。 ドロップに関連して新たに提案された保証は、「物が漏れない」と言っているのではありません。 「最初にdropが呼び出されない限り、割り当てが解除されることはありません」と書かれています。 それは非常に異なるステートメントです。 この保証はthread::scopedは役立ちません。

コンテキストを追加するために、 Futureを実装する構造体からデータを移動することは、私が一般的に行うことです。 フューチャーがポーリングされて完了しなかった場合（ポーリングが完了する前にドロップされた場合）、クリーンアップ作業を実行する必要があることがよくあります。

したがって、 mapドキュメントが追加されていても、既存のコードをfutures 0.3に移植するときに、私は間違いなくこの地雷にぶつかったでしょう。

@carllerche map関数は、これを使用して何かを移動してはならないことを明確に示しています。 Pin<T>から故意に移動する人々から保護することはできませんし、したくありませんが、これを行うには（安全でないコードを使用して）邪魔にならないようにする必要があります。 私はそれを地雷とは呼びません。

それで、あなたはどの地雷を参照していますか？

@RalfJung私はピン留めされた参照のマッピングの限界を自分で理解しようとしてきましたが、すぐに解決されなければ、これは巨大な足がかりになると思います。 複雑さにもかかわらず、最初の解決策が望ましいと思います。 固定されたフィールドに安全に投影できないと、消費者が安全でないコードを記述せずに固定に依存するAPIを実際に使用することは事実上不可能になります。

これができない場合、実際には、ピン留めを使用するほとんどの使用可能なAPIはPinShareを使用する必要があると思います。 これはそれほど大きなハンディキャップではないかもしれませんが、その場合のUnpinとの関係についてはまだはっきりしていません。 具体的には、ピン共有参照を取得して、型のフィールドへの参照を取得するとします（特定の存続期間中）。 その寿命が終わったら動かないことを本当に信頼できますか？ フィールドが!Unpinあれば、おそらく可能です。 Pinが投影できない限り、問題ないかもしれません。ほとんどの場合、列挙型が心配です。 ドロップを修正しないと共有ピン留めでさえ安全ではないと言っているのでない限り、その場合、ピン留めで機能するようにドロップを修正する必要があると思います。 そうしないと、実際には安全に使用できないニッチなライブラリ機能になり、Futuresに非常に役立つ場合でも、コア言語での地位に値するものではありません（IMO）。

また、これまでのところ侵入型コレクション用に持っている唯一の実用的なAPI（まだねじれを解決する必要があります）には、それよりもさらに強力な保証が必要です。 それは、ドロップが長いコレクションに任意のボローがあると呼ばれていないことを保証できるようにする必要があります。 GhostCellスタイルの手法を使用してこれを行うことはできますが、非常に扱いにくく、ユーザーが手動でメモリ管理を行う必要があります（トークンが提供されずにコレクション内の何かのバッキングメモリが削除された場合、リークする必要があるため）。 そのため、自動ドロップ自体が、ピン留めを興味深い方法で使用するタイプでは機能しないように思われるのではないかと少し心配しています。

好奇心から：追加賛否両論何UnpinにバインドDrop ？ 下位互換性を引用しましたが、代わりに、ドロップされたものを何らかの方法で自動的にバインドする必要がありますが、他の特性には存在しない、すでに奇妙なタイプのシステムレベルの制限をドロップします-なぜこれがそれほど異なるのですか？ 確かに、ドロップをPin<T>取るほどエレガントではありませんが、現時点では実際にその変更を行うことはできません。 あなたが唯一持っているタイプのコールドロップ行う場合、我々は実際に何をするか分からないという問題であるUnpin実装を型自体である場合には、 !Unpin ？ ジェネリック型の実行にdropを依存している人は、すでにパニックのケースを処理する必要があるため、その場合にdrop実装で例外をスローするのが正しいアプローチかもしれません。 つまり、新しいDrop特性を使用するようにコードを更新する多くの人々がいなければ、実際に!Unpinタイプを使用することは非常に難しいことを意味します（したがって、エコシステムはすべてをに移動することを余儀なくされます新しいバージョン）ですが、それでも健全性を維持し、 !Unpinをまったく使用しなかったコードを壊さないので、私はそれで大丈夫だと思います。 さらに、「ライブラリがアップグレードされない場合、コードがパニックになる」ことは、人々に先に進む動機を与えるでしょう。

実際、これが私の提案したデザインです：

ピンを取る2番目の方法でドロップ特性を拡張します、あなたが提案したように。 特殊化されたデフォルトの実装where T: Unpinコールドロップを作成します（これは現在の特殊化ルールに合格すると思いますか？しかし、そうでない場合でも、 Dropは常に特殊化できます。さらに、 Drop関数は通常自動生成されます）。 これで、上記で提案したのとまったく同じ動作が得られます。下位互換性の問題はなく、不自然に境界を自動導出する試みもありません。

!Unpinタイプで実際に役立つようにするには、サードパーティのライブラリをアップグレードする必要があるという問題がありますが、私が言ったように、これは間違いなく良いことです。 いずれにせよ、 &mutを必要とする方法で実際にフィールドを変更するdrop実装の数はわかりません。私が考えることができるもののほとんどは、 unsafe使用して何か面白いことをします。

このアプローチの主な点は、それが採用された場合、 Pinが安定する前に採用されなければならないということです。 これが、 Pinが急いで入らないことを本当に望んでいるもう1つの理由です。設計の結果を十分に調査したとは思いません。

：（私は1つ以上の潜在的な問題を参照くださいManuallyDrop誰かが、おそらくその前提としたジェネリック型以上のデストラクタ書かれている可能性があることや、一般的な平均で労働組合をdropそれはパニックことができませんでし内の実装を、それは実行することができなかったという理由だけで（また、他の呼び出すことが許可されません&mutパニックしないと約束という危険な特性に実装されたものを除いて、一般的なT上の機能を）。以来Pinは、メモリが破壊される前にドロップ実装が実行されることをすでに保証する必要があります[新しいセマンティクスによる]、その目的で使用されるManuallyDrop内の!Unpin型はそもそも既存のコードではピン留めされているとは見なされなかったので、その仮定をしていれば既存のコードは正しいはずです。確かに、ピンをManuallyDropに安全に投影することはできないはずです。ドロップの前にデストラクタが呼び出されることを保証した場合にのみ安全です。このケースをコンプにどのように伝えるかはわかりません。 同様の目的を意図しているように見えるので、これは「眼帯」のものをまったく利用できますか？]。 それが意味的に飛ぶかどうかはよくわかりませんが、おそらく既存のコードのDrop実装の目的で機能します。

眼帯に関しては...正確な正式な定義はまだわかりませんが、Tで興味深いジェネリック関数が呼び出されないという一般的な考え方がある場合は、それをさらに活用できるでしょうか。 つまり、 !Unpinタイプのdrop_pinned実装が実装された場合、眼帯を尊重するコンテナは正しく動作します。 1つが、その後のコンパイル時の失敗ができることを私には可能と思われる!Unpin実装タイプDrop 、実装されていませんdrop_pinned 、およびそのジェネリックパラメータは眼帯していない、で自己参照型の有効期間を持つ非眼帯コンテナを使用する場合と同じ方法です。

ただし、存在は、コンパイル時の戦略との重大な下位互換性のリスクをもたらします。 そのため、実行時に失敗するソリューションの方が現実的だと思います。 これには実行時の障害はなく、誤検知もありません。

編集：私たちは本当にだけではない、デストラクタでアクセスフィールドを心配する必要があります：実際には、上記のすべてのスクラッチ&mut正しい、アクセス一般的に？ &mut selfからの暗黙のフィールドプロジェクションについてのみ心配しているからです。

私は!DynSized提案を再発明しているだけかもしれませんが、本質的には、一般的なコンテナーは、ピンの型状態を気にするメソッドを公開する場合、すでに!Unpin必要があります（これは、誤ったパラメトリシティのように疑わしいように聞こえます議論が、私を聞いてください！）。 Box<Trait>や&mut Traitような存在は、必ずしもそれらのUnpinステータスを反映しているわけではありませんが、（少なくとも現在のAPIを見つめているからですか？） Pin<Box<T>>とは思いませんPin<&mut T>は、必然的にPin<T>に強制可能である必要があります。ここでT: !Unpin ; これを実装しないと、これらのタイプへの固定参照が内部への固定アクセスを安全に提供しないことを意味します（＆mutと＆の関係でこれにいくつかの前例があることに注意してください：＆mut＆Tは＆mut Tに強制できず、＆TとBox <＆mutT>はBox<T>に強制できず、＆mut T;のみです。一般に、異なる型状態が衝突した場合、それらを自動的に伝播する必要はありません）。 通常、 &mut T 、 Box<T> 、およびTは、型状態の観点から完全に交換可能であると見なされ、この引数は仮想のインライン存在に拡張されないことを認識していますが、おそらくこれはDynSize提案の内容（特性オブジェクト値の安全なスワップまたはmem::replace許可しないでください、私は推測しますか？実際には、すでに許可されていません...しかし、私はあると思いますこれが将来変更される可能性がある理由）。 これにより、コンパイル時のソリューションが非常に簡単になります。（推移的に）直接所有する構造体（＆mut、＆、 Box 、またはrawポインターなし-いずれもPinアクセスを安全に推移的に伝播しません） 、共有ピンの&を除きますが、 &はとにかく移動できません。または、「特性オブジェクトから移動できない」ソリューションを使用することにした場合は、 &mutとBoxに沿って推移的にフィールドをチェックすることもできます）、既知の!Unpinタイプ（それ自体を含む）に（可視性の意味で）アクセスできます。 2番目の種類のdrop実装します。 安定した型は!Unpinではないので、それは完全に問題なく、下位互換性のフットガンではないように思えます。ライブラリを更新した後、デストラクタを再実装する必要があるかもしれませんが、それだけですよね？ さらに、内部実装の詳細は内部にとどまります。 !Unpinフィールドが公開された場合にのみ、問題が発生します。 最後に、すべての汎用コンテナタイプ（ Vecと標準ライブラリのものだけでなく、基本的にcrates.ioエコシステム全体）は引き続き正常に機能します。 このソリューションについて私が見逃している壊滅的なことは何ですか？

（実際、 drop定義時にこれを強制できなかったとしても、少なくともdropckように、型のインスタンス化時に強制できるはずです。完全にインスタンス化された型についてのみ心配する必要があるため）。

Dynsized提案を読み直す：それに対する議論では、固定される前であっても、不動の型は常にDynSizedである必要がありました。 私は上記で、特性オブジェクトの場合にのみこれについて心配する必要があると主張します。 !Unpin型をトレイトに強制的に強制するには、それを+ ?DynSized明示的にバインドする必要があることを強制することは可能かもしれません（正当化するのは難しいですが）。 !Unpinタイプのサイズを知っている必要がある場合（実際、私にはそのようなユースケースがあります！）や、固定する前に交換できる必要がある場合が多いかもしれませんが、あるといいのですが。不動の型から作られた特性オブジェクトの内部のそのようなケースはほとんどありません（現在の唯一のケースは、明示的に禁止したいBox -> Rc変換のようなものですよね？ Pin<'a, Box<Trait>をPin<'a, Trait>に変えることができるかどうかはまだわからないので、 size_of_valが公開されていることが本当に問題であるかどうかは私にはわかりません。 Pin<'a, Trait>ですが、それができない場合は、もちろんSizedに頼ることができます）。 いずれにせよ、本当に!Unpinでそれらをバインドできるようにしたいのですが、私が言ったように、人々は私たちがすでに必要としているよりも多くの否定的な特性を追加することを避けたいと思います（個人的には、 !Unpin形質オブジェクトは、形質が持つオブジェクトの境界ことを十分に稀で、特殊なことを行っている?UnpinではなくUnpin完全に合理的であるとあまりにも多くの種類のシステムに感染していないでしょう。用途のほとんどのために!Unpin通常、 Pin<self>アクションを実行する必要があるため、ほとんどの既存の特性に役立つ実装はないと思います。通常は、 PinBox使用することもできます。またはPinTypedArenaまたは?Unpin境界がかなり自然に見える時点で）。

新しいデザインがありますが、古いデザインほどひどいものではないと思います： https ： @ RalfJungが提案したPinDropトレイトを使用しているようですが、両方ともカスタムドロップがあり、フィールドを投影したいタイプにのみ

タイプは、「現代の」Rustで記述されたコードに類似した、投影フィールド（ PinFields特性の導出に対応）を明示的にオプトインします。 ただし、「レガシー」Rustのコードには追加の要件はなく、代わりに、 PinFields任意の派生に対して深さ1への投影のみをサポートすることを選択します。 また、参照を介してPinを移動しようとはしません。これは、とにかく実行しないことをお勧めします。 同一のフィールドとバリアントを持つ構造を生成することで、Rustが提供できるはずの非結合分析を含む構造と列挙型をサポートしますが、型はPin 'dの型への参照に置き換えられます（些細なことです）。その変更が行われたときにこれをPinとPinMutに拡張します）。 明らかにこれは理想的ではありませんが（オプティマイザーがほとんどを取り除くことができるといいのですが）、borrowckとNLLで動作し、（生成されたアクセサーとは対照的に）列挙型で簡単に動作するという利点があります。

安全性の議論は、Dropが構造にまったく実装されていないことを確認するか、Dropが実装されている場合、PinDrop（Pinを使用するDropのバージョン）のみを呼び出す簡単な実装であることを確認することによって機能します）。 これにより、固定されたフィールドの投影に関するすべての健全性の問題が除外されると思います。疑問符が1つあります。私の主な関心事は、まったく同じコンテナ上の互いに素なフィールド（つまり、深さ1のフィールド）が互いに無効になる理由についての適切な議論を見つけることです。デストラクタのピンは、ピンの突起がないとすでに無効になります。 別々のPinBoxで開催された場合にも同じことができることを示すことができれば、これを正当化できると思います。つまり、彼らが住んでいる

@pythonesque DynSizeについてあなたが上で書いたことに実際には従いませんでしたが、とにかく今はすべて時代遅れだと思いますか？ だから、私はあなたの最新の投稿にコメントするだけです。

要約すると、構造体/列挙型のフィールド（ pubフィールドを含む）への射影は一般に安全Drop実装しオプトインできDrop 。 型はデストラクタを望んでいるなら、それはに持っているPinDropの代わりにDrop ：

trait PinDrop {
  fn pin_drop(self: PinMut<Self>);
}

我々はすでにのためです。TypeCheckの外観を持っているDrop 、また、チェックするために非現実的なようではありませんので、フィールドの外に移動拒否するDropを通じて投拒否する&pin 。 もちろん、「フィールド外への移動」チェックは、 PinDropがある場合でも拒否されますが、その場合は予測が許可されます。

コンパイラは、 Dropに適用されるのと同じ制限をPinDropに適用します。さらに、型がDropとPinDrop両方を実装しないようにします。 ドロップグルーを生成するとき、タイプが実装したあらゆる種類のDropを呼び出します。

それは提案を要約していますか？ 私が理解していない部分はあなたの最後の段落です、あなたが心配していることを示す例を挙げていただけますか？

さて、もちろん、私はここで証明義務が何であるか疑問に思っています。 これを確認する最も簡単な方法は、 PinDropが実際には正式に存在する唯一の主要なデストラクタであり、 impl Drop for Tは実際にはimpl PinDropシンタックスシュガーであると言うことだと思います。安全でないメソッドPinMut::get_mutを呼び出してから、 Drop::drop呼び出します。 これは自動生成された安全でないコードですが、ピン留めは「ローカル拡張」であるため（つまり、既存の安全でないコードと下位互換性があります）、特定のタイプがピン留めを気にしない場合、その安全でないコードは常に安全です。

もう少し正式に言えば、作成者がピン留めを気にしない場合にタイプが持つ「デフォルトのピン留め不変条件」があります。 そのデフォルトのピン留め不変条件を使用するタイプは、自動的にUnpinます。 カスタム不変条件を持つタイプにimpl Dropを書き込むと、そのタイプは「デフォルトのピン留め不変条件」を使用すると主張します。 ここに証明義務があったように感じるので、これは少し怪しいですが、これについて警告するunsafeはありません-実際、これは完全ではありませんが、下位互換性が重要なので、何ができますか行う。 これが実際に意味することは、安全でないコードが「デフォルトのピン留め不変条件」で機能しなければならないという範囲で、安全でないコードで発生する証明義務を変更することであると主張できるため、これも大惨事ではありません。 このモジュールの他の場所に安全でないコードがない場合は、すべて問題ありません。

T: Unpinでない限り、 impl Drop for Tに対して糸くずを追加できると想像することもできます。おそらく、型を定義するモジュールに安全でないコードが含まれている場合に限定されます。 これは、問題について人々を教育する場所であり、 unsafe impl Unpin （デフォルトのピン留め不変条件を使用することを正式に主張する）またはimpl PinDropいずれかを奨励します。

@RalfJung

それは提案を要約していますか？

はい、多かれ少なかれ（Dropが実装されていない場合、自動的にプロジェクションを実行することを提案しているように見えるので、あなたの提案は実際には私の提案よりもはるかに野心的だと思います。これはおそらくライブラリの上位互換性の問題だと思いますが、何らかの方法があるかもしれません。それ）。

私が理解していない部分はあなたの最後の段落です、あなたが心配していることを示す例を挙げていただけますか？

大まかに言えば、同じ構造上に直接存在する2つのフィールドが心配です。一方は、ドロップが呼び出されたときにもう一方を変更します（おそらく、安全のためにドロップ順序などに依存します）。他のフィールドですが、その構造的整合性は保持されます（したがって、ピン留め不変条件の違反を目撃できます）。 これは明らかに完全に安全なコードを使用することはできません（そうでなければ、とりわけdropckによって拒否されます）ので、私の懸念は、フィールドが別々に固定されているときにフィールドタイプのデストラクタが安全に実行できるといういくつかの仮定のケースについてのみです構造物ですが、同じ構造物に固定されている場合は安全ではありません。 フィールドが含まれている構造を含む共有不変条件がない限り、そのようなケースがないことを願っています。 そのような不変条件がある場合、そのコンポーネントがカスタム不変条件を適切に尊重していないことに注意する必要があることを知っているため、モジュールのどこかでコードを非難することができます。

これを確認する最も簡単な方法は、PinDropが実際に正式に存在するメインで唯一の種類のデストラクタであり、impl Drop forTは実際には安全でないメソッドPinMut :: get_mutを呼び出してから呼び出すimplPinDropの構文糖衣構文であると言うことだと思います。ドロップ::ドロップ。

同意しました。 残念ながら、この方法は、ライブラリで処理を実行しようとするため、現在のソリューションに対して開かれていませんでした。

もう少し正式に言えば、作成者がピン留めを気にしない場合にタイプが持つ「デフォルトのピン留め不変条件」があります。 そのデフォルトのピン留め不変条件を使用するタイプは、自動的にピン留め解除されます。 カスタム不変条件を持つタイプに対してimplDropを記述すると、そのタイプは「デフォルトのピン留め不変条件」を使用すると主張します。 ここに証明義務があったように感じるので、これは少し怪しいですが、これについて警告するのは危険ではありません-実際、これは完全ではありませんが、下位互換性が重要なので、何ができますか？

はい、これは大まかに私が考えていることです...この「モジュール内の安全でないコード」の保証を実際に形式化することの意味について、私には十分な直感がないのではないかと心配しています。 私はあなたの糸くずのアイデアが好きです（実際、PinDropを使用する人を増やすものは何でも好きです！）が、 unsafe impl Unpinはおそらくあまりにも頻繁に間違っているので、提案するのは良いことではないと思います。少なくとも一般的なパブリックフィールドを持つ型の場合（ただし、そのようなフィールドを持たない構造の場合、実際にはかなり頻繁に当てはまります...たとえば、標準ライブラリの場合はほぼ当てはまります）。

#[derive(PinnedFields)]がどのように機能するかの例を書きました： https ：

私は人々がこのような派生物は「健全ではない」が真実ではないafaikであると主張するのを見てきました。 この派生によって生成されたコードと競合する何かを行うには、安全でないコードを使用する必要があります-つまり、これにより他の安全でないコードが不健全になります（そして、コード（ ?Unpinデータを移動する）は次のようなものだと思いますあなたは常に避けることができる/すべきです）。

編集：さて、実際にデストラクタに関する最後のいくつかの投稿を読んでください。 処理します。

@withoutboatsええ、あなたはすでにこれを見たと思いますが、問題は、正しい!Unpinタイプの安全でないコードが、 PinFieldsを派生させたタイプの安全なデストラクタによって無効化される可能性があることPinFieldsを派生させたタイプのモジュールには安全でないコードはありません#[derive(PinFields)]がまだ機能することは間違いありません。 Dropが直接実装されていないことを確認する必要があります。

また、私が考えていた別のポイントを取り上げたいと思います（まだどこにも直接解決されていないのですか？）： Pinはるかに使いやすくし、既存のコードにうまく統合できるものだと思います。本質的にすべてのポインタタイプがUnpinであるという側面にしっかりと立ち向かうことになるでしょう。 つまり、 &mut T 、 &T 、 *const T 、 *mut T 、 Box<T>などをすべてUnpinと見なします。 任意のためのT 。 たとえば、 Box<T>をUnpinにするのは難しいように思えるかもしれませんが、の内部にPinを取得できないことを考えると理にかなっています。 BoxうちPin<Box<T>> 。 これは、 !Unpinのみが「インライン」であるものに感染することを許可することは、非常に合理的なアプローチだと思います。参照間でピン留めをバイラルにするための単一のユースケースはありません。任意の最終的な&pin型は非常に（私はそれがそのシナリオ内の他のポインタ型と相互作用する方法については、テーブルを働いた、とあなたが移動を無視し、基本的にあれば、それは可能喜ば&mut pinと同じ行動&mut 、 &pinは&と同じように機能し、 box pinは他のポインターとの関係に関してboxと同じように機能します）。 私が知る限り、これは操作上も重要ではありません。一般に、タイプB値へのポインタを含むタイプAの値を移動しても、のポイントされた値は移動しません。タイプB 、タイプBの値がタイプAの値にインラインでない限り、-しかしその場合、 Aは自動的に!Unpinには、ポインタの間接Bなしで!Unpin手動で安全でない実装を必要とするタイプの大部分は、ポインターの間接T背後にDrop作業を継続するために、これらのタイプが実装できるようにするPinDropのタイプがある場合ので、（その意味を変えずにUnpinそれは扱うことができますPin 'd引数&mutとにかく

この種の推移的なピン留めが良い考えである理由を私は見逃しているかもしれませんが、これまでのところ私は何も見つけていません。 私が心配するかもしれない唯一の操作上のことは、自動特性でこの動作を実装することが実際に可能かどうかです-おそらくそうなると思いますが、人々がPhantomData<T>が、実際には所有している場合もありますTへのポインタ、それをPhantomData<Box<T>>に変更するとよいでしょう。 通常、これらは意味的にはまったく同じであると考えていますが、ピン留めでは完全に真実ではありません。

@pythonesque 「新しい言語」などの用語は、私にとって状況をかすんでいるようなものです。 あなたがしていることの私の印象は：

• デフォルトでは、 #[derive(PinFields)]はno-op Drop implを生成します。 これにより、デストラクタの固定フィールドにアクセスしないことが保証されます。
• オプションの属性は、この変更DropコールするのimplをPinDrop::pin_drop 、そしてあなたが実装することになっているPinDrop 。

これは正解？

また、侵入的なコレクションをサポートするためにPinの保証を拡張した場合にのみ、このすべてが問題になると思います。 これは、 @ RalfJungと@pythonesqueの理解と一致していますか？

DropはPinだけ自分自身を取る

固定されたフィールドへの不健全なアクセス+ドロップが原因で発生する可能性のある種類の例を次に示します：

タイプFooは、内部バッファーをある種の外部APIに渡しており、明示的にリンクが解除されるまでバッファーをそのままにしておく必要があります。 これは@cramertjが提案した制約の下で健全であると私が知る限り、 Pin<Foo>が作成された後、 Dropが呼び出されるまで移動されないことが保証されます（代わりにリークされる可能性があり、 Dropが呼び出されることはありませんが、その場合は移動されないことが保証されます）。

次に、タイプBarは、 Drop実装中にFoo移動することにより、これを破ります。

DMAを介して通信する無線周辺機器をサポートするためにFooと非常によく似た構造を使用していますが、無線によって書き込まれる内部バッファーを備えたStableStream持つことができます。

@withoutboats

これは正解？

はい。ただし、実際には何もしないDrop implは生成されません（RustでDropを実装しないタイプの方が一般的にうまく機能するため）。 代わりに、 Dropがいくつかの魚のようなライブラリ機能を使用して実装されていないことを主張しようとします（安定して動作しますが、特殊化の下で壊れます-特殊化の下で動作するはずのバリアントがあると思いますが、現在は動作しません関連する定数に関する問題の）。 言語機能にした場合、これを強制するのは非常に簡単です。

また、侵入的なコレクションをサポートするためにPinの保証を拡張した場合にのみ、このすべてが問題になると思います。 これは、 @ ralfjと@pythonesqueの理解と一致していますか？

いいえ、残念ながらそうではありません。 上にリンクされた反例は、侵入的なコレクションに対する追加の保証とは何の関係もありません。 Pin 'd型は、ピン留めされた参照の背後から値に対してメソッドが2回呼び出された場合、その値がそれが2つの呼び出しの間を移動したかどうかを知る方法はありません。 煩わしいコレクションに役立つようにするために必要な追加の保証は、メモリが解放される前にdropを呼び出さなければならないという追加のことを追加しますが、その保証がなくてもdropは何かで呼び出すPinBoxフィールド値）、次に、以前に固定されたときからの参照がまだ有効であると期待しているメソッドを呼び出します。 私はそれを回避する方法を実際には見ていません。 drop実装できる限り、インラインの!Unpinフィールドでこの問題が発生する可能性があります。 だからこそ、最も悪い解決策は、ピン留めして正しく機能させたい場合に、 drop実装させないことだと思います。

ドロップはピンで自分自身を取るべきであることが明らかであるため、これはすべてかなりイライラします！ より根本的な（おそらく画期的な）変更を加えることは魅力的なようですが、それほど破壊的ではない方法は見当たりません。

ええ、それは本当に迷惑です...私はそれについて約1週間非常に不機嫌でした。 しかし、ラルフが指摘したように、誰かがこれを理解する前に、1.0まであと3年待たなければならなかったでしょう...そして常にもっと何かがあるでしょう。

ドロップされたものにインラインフィールドが含まれていて、ドロップされたものからそれらのフィールドにピンを投影できる場合、外部タイプのデストラクタは引き続き内部フィールドを移動し、からの参照を期待しているメソッドを呼び出すことができます。まだ有効であるように固定されたとき。

強調された部分は私には非常に大きな問題のように思えます。 実際、それは問題の核心のようです。

最初に私はこのコードを想像しました。これは、実際に内部アドレスを気にする唯一の方法を使用しています。

struct TwoFutures<F>(F, F);

impl Drop for TwoFutures {
     fn drop(&mut self) {
          mem::swap(&mut self.0, &mut self.1);
          unsafe { Pin::new_unchecked(&mut self.0).poll() }
     }
}

しかし、 Pin戻るには、安全でないコードが必要です。 そのコードは単に不健全であると見なされるべきです。

&selfと&mut selfを使用するメソッドが、健全性のために内部アドレスの有効性に依存する機能を除外できますか？ それはどのように見えますか？

@withoutboats Pin<Self>を取るメソッドだけが健全性のために内部アドレスの有効性に依存している場合でも、問題が発生する可能性があります。 外側の型のデストラクタは、内側の型のフィールドをmem::replace （独自の&mut self参照を使用）、次に値をPinBox::newて、固定されたメソッドを呼び出すことができます。 安全ではありません。 固定されたフィールドを投影できなくても問題にならない唯一の理由は、 unsafeを使用して奇妙な!Unpinメソッドを実際に実装する（または、実行する型と不変条件を共有する）型に受け入れられると見なされるためです。 ）安全なコードのみを使用している場合でも、 drop実装に証明義務を負わせる。 しかし、たまたま!Unpin型が含まれていて、それ自体に安全でないコードがない型については、尋ねることはできません。

@pythonesque

Dropが実装されていない場合、自動的にプロジェクションを実行することを提案しているように見えるので、あなたの提案は実際には私の提案よりもはるかに野心的だと思います。これはおそらくライブラリの上位互換性の問題だと思います。 しかし多分それを回避する方法があります

やがてやりたいと思います。 互換性の問題はどうですか？

同じ構造に直接存在する2つのフィールドが心配です。一方は、ドロップが呼び出されたときにもう一方を変更し（おそらく、安全のためにドロップ順序などに依存します）、もう一方のフィールドの固定不変条件に違反します。ただし、その構造的整合性は保持されます（したがって、ピン留め不変条件の違反を目撃できます）。

しかし、それは現在すでに違法です。 他人の不変条件に違反してはなりません。

しかし、少なくとも一般的なパブリックフィールドを持つタイプの場合、安全でないimpl Unpinは、おそらくあまりにも頻繁に間違っているため、提案するのは良いことではないと思います。

私はほとんどの人がのために任意のアクセサ提供することはありません期待して-私はそれが実際にはほとんどの時間を正確になると思うPin<Self> 、その場合には、彼らはおそらく不変を固定デフォルトを使用しているので、それがに大丈夫ですunsafe impl Unpin彼らのために

Pinをはるかに使いやすくし、既存のコードにうまく統合できるようにするためには、基本的にすべてのポインタータイプがUnpinであるという側面をしっかりと理解する必要があると思います。 つまり、＆mut T、＆T、* const T、* mut T、Boxを作成します、などはすべて、どのTに対しても固定解除と見なされます。たとえば、Boxのようなものを許可するのは怪しいように見えるかもしれませんが、ピンを外すには、ピンからボックスの内部にピンを取得できないことを考えると理にかなっています。>。

これが発生する可能性があることに同意します（https://github.com/rust-lang/rust/pull/49621#issuecomment-378286959のコメントも参照してください）。 現在、ピン留めの全体に自信が持てるようになるまで少し待つ必要があると感じていますが、実際、ポインターの方向を超えてピン留めを強制する意味はほとんどありません。
生のポインターに対してこれを行うことについて私がどのように感じているかはわかりませんが、それらはあらゆる種類のクレイジーな方法で使用されるため、通常、それらの自動特性については非常に保守的です。

@withoutboats

＃[derive（PinnedFields）]がどのように機能するかの例を書きました： https ：

@pythonesqueはすでにこれを言っていますが、これは明確にするためです：そのライブラリは@MicahChalmerのドロップの問題でそれを使用すると、実際にピン留めに依存しているピン留めされたタイプを壊すことができます。 これは、ドロップが呼び出されることに関する追加の保証とは無関係です。 例がまだ必要かどうか教えてください。 ;）

@RalfJung

その図書館は不健全です。

明確にするために、派生はunsafeであり、手動のDrop implと組み合わせて使用​​することはできません。 派生を使用することにより、 Drop実装にリストされている悪いことをしないことを約束します。

https://github.com/rust-lang/rust/pull/50497はピン留めAPIを変更します。最も重要なのは、共有Pinを追加するためのスペースを確保するために、 Pin名前をPinMutに変更することです。将来的にはPin 。

明確にするために、派生は安全ではなく、手動のDropimplと組み合わせて使用​​することはできません。

同意しました、そのようにそれを危険にすることはうまくいくでしょう。 テストでは現在のように見えますが、実際には安全でないとマークされていませんか？

@RalfJungそうですね、現時点ではそうは思いません。 私が今考えたもう1つのオプションは、「安全な」バージョンでそのタイプのDrop実装を作成し、 Drop他の手動実装をブロックすることです。 これをオフにするためのunsafeフラグがある可能性があります。 WDYT？

@cramertjはい、それも機能するはずです。 ただし、より制限的なdropckや、フィールドから移動できないなどの副作用があります。

@pythonesqueと私は月曜日にこれについて話し合うために電話をしました。 これが要約です。

おそらく「正しい」振る舞いは、 Dropがピンで自己を奪うことだったと結論付けました。 ただし、それに移行するのは困難です。 私が信じている何らかの形でエディションを変更することは可能ですが、これは非常に混乱を招くでしょう。

下位互換性のある変更は、 Dropを実装するために「ピンプロジェクション」できるタイプに対して何らかの形で一貫性を欠くようにすることです。 彼のリポジトリでは、 @ pythonesqueは、複雑な特性のセットからimplを生成することでこれを実装しています。

少し単純な組み込みフォームを想像することができます。

• マーカー特性（ PinProjectionと呼びましょう）は、タイプをピン投影できるかどうかを制御します。 PinProjectionとDrop両方を実装することは、（コンパイラーの組み込みの魔法によって）一貫性がありません。
• 別の特性PinDrop 、 PinProjectionを拡張して、 Drop代替デストラクタを提供します。

もののようなピンの投影方法を生成するための派生は@pythonesqueと私はまたのimpls生成されますが示されているPinProjectionタイプするために。

@withoutboats

おそらく「正しい」振る舞いは、Dropがピンで自己を奪うことだったと結論付けました。 ただし、それに移行するのは困難です。 私が信じている何らかの形でエディションを変更することは可能ですが、これは非常に混乱を招くでしょう。

いつかそのようなことをしたいと思ったら、将来互換性のあるものを提案しているのでしょうか。

たとえば、私たちが決めたとしましょう...

• Drop魔法のように固定フォームと非固定フォームの両方を受け入れるようにする、または
• Rust 2021への自動アップグレードの一環として、全員のDrop署名を書き直します:)

（私はこれらのどちらも提案していませんが、具体的な例なしに質問に答えるのは難しいようです。）

@tmandryそれは本質的にアイデアです。

大きな問題は、typeパラメーターを移動する一般的なDrop実装です。

struct MyType<T>(Option<T>);

impl<T> Drop for MyType<T> {
    fn drop(&mut self) {
        let moved = self.0.take();
    }
}

あなたが話している種類の自動アップグレードは、このDrop implを壊すだけです。これは、 T: Unpinという境界を追加した場合にのみ有効です。

デストラクタ内で実際に?Unpinデータを移動するための有効な使用例はわかりません。したがって、技術的には可能であるが意図されていないこの場合、それは本当に問題です。

@withoutboats

もう1つの特性であるPinDropは、PinProjectionを拡張して、Dropの代替デストラクタを提供します。

PinDropがPinProjection拡張するのはなぜですか？ それは不要のようです。

また、タイプがUnpinない限り、 PinProjectionとDropは互換性がないと言うことで（またはこれらの新しい区別/制限をすべて削除する他の方法を見つけることで）、これを少し賢くすることができます。 Unpinタイプの場合）。

@RalfJung PinDropとDropを何らかの形で相互に排他的にしたいと思います。 最終的には、さまざまなトレードオフでこれを実装する方法がいくつかあります。 小さな変更ではないので、RFCが必要だと思います。

@withoutboats同意しました。 独占権はPinDrop特別な扱いから生じる可能性があると思いましたが、それを行うには明らかにいくつかの方法があります。 Unpinタイプが気にする必要がなければ、それは非常に便利だと思います。 すべてのポインタ型を無条件にUnpinするとともに、これはおそらく人々がこれについて知らなければならないケースの数を減らすのに役立つでしょう。

@withoutboatsまた、人々がデストラクタのVecで一般的なデータを移動したい場所について考えることができる主なインスタンス（IIRCの人々がしたいのでVecた）も注目に値します。 Vecを実際に気にするUnpin実装することはできませんPin 。これは、実際には&mut Vec<T>またはVec<&mut T>か何か。 これらはおそらく@RalfJungが提案した糸くずによってunsafe impl UnpinではなくPinDrop簡単に移動できるようになることを願っています。 （理論的には、もちろん、 TをタイプのUnpinで制限することにより、常に前者を実行できますが、それはライブラリのクライアントにとって重大な変更になります）。

また、これは私たちが望むよりもいくつかの特性を追加しますが、特性はほとんど誰のタイプシグネチャにも表示されないものであることに注意してください。 特に、 PinProjectionは、 #[derive(PinFields)]マクロを記述していない限り、完全に無意味な境界です。コンパイラーは、可能であればPinProjectionが成立するかどうかを常に判断できるからです。タイプのフィールドが何であるかを理解し、それが役立つのはフィールドを投影することだけです。 同様に、 PinDrop Dropがバウンドとして使用されることはほとんどないのと同じ理由で、 PinDropは基本的に何かのバウンドである必要はありません。 トレイトオブジェクトでさえほとんど影響を受けないはずです（いつか「関連付けられたフィールド」を取得しない限り、私は推測しますが、そのような新しい機能を使用すると、関連付けられたフィールドを持つトレイトはPinProjectionタイプでのみ実装可能であることが義務付けられます。その問題）。

@RalfJung

やがてやりたいと思います。 互換性の問題はどうですか？

SendまたはSyncを実装しないタイプを追加するだけで、どちらもコア言語にまったく影響を与えないという違いがあると思います。 それを完全に自動的に行うことは、RustがCopyを処理するために使用した方法に類似しているようです（タイプがCopyタイプのみを含み、 Drop実装しなかった場合、タイプは常にCopy Drop ）これは最終的に変更されて明示的になりました。おそらく、特性（ Drop ）を追加すると、それを認識せずに一般的なコードが破損する可能性があるという事実が気に入らなかったためです（一貫性の全体的なポイントは追加であるため）特性の実装は、下流の箱を壊してはなりません）。 これはちょうどで、ほぼ同じようでPinProjectionの代わりにCopy 。 私は実際に古い振る舞いが好きでした。 Copyがそうでない場合、 PinProjectionこのように機能することを正当化するの

しかし、それは現在すでに違法です。 他人の不変条件に違反してはなりません。

ええ、これについて考えれば考えるほど、問題になる可能性は低くなります。

ほとんどの場合、実際には正しいと思います

ええ、そうですが、ほとんどのタイプがPinを必要とするメソッドを実装していないか、汎用フィールドをパブリックとして公開していないためです。 後者は変更される可能性は低いですが、前者は変更されません。現在!Unpinであるstdlibタイプの少なくとも一部は、ピン投影メソッドを追加することを期待しています。その時点で、 unsafe実装は変更されません。もう有効ではありません。 ですから、私にはかなり壊れやすいもののように思えます。 さらに、人々が書かなければならない「ボイラープレート」の危険なコードの量が増えるのではないかと心配しています。 SendとSync境界は、正しく実装されていないのとほぼ同じ頻度で正しくunsafe impl 'dされていると思います。また、 Unpinは、通常、正しいバージョンにはT制限はありません。 したがって、人々をPinDrop向けるのが非常に望ましいようです（ただし、生のポインター型に対してそれを行うことに慎重な理由は理解できます。すでにunsafeコードがそうなるのではないかと心配しています。考えずにunsafe implを実行する可能性はさらに高くなりますが、考えれば考えるほど、生のポインターのデフォルトはおそらく正しいように思われ、糸くずでフラグを立てると便利です）。

Unpinタイプが気にする必要がなければ非常に便利だと思います。

私はある程度同意しますが、私が言ったように、人々は実際の境界としてPinProjectionを使用しないので、実際にどれだけ重要かはわかりません。 PinMutはすでにDerefMut実装があり、 T: Unpinため、今日はそれから何のメリットも得られません。 コンパイラに実装されたルール（プロジェクション用）は、おそらくPinMut::newをUnpinタイプの一種の&pin再借用に変換しますが、それは実際にはフィールドプロジェクションとは関係ありません。 また、 PinProjection導出する場合、そのフィールドにPinProjectionは必要ないため、別のタイプのderive範囲を満たすためだけに必要になることはありません。 本当に、利益は何ですか？ それが実際にできる唯一のことは、 Dropを実装し、同時にPinProjectionsを導出することですが、とにかく可能であれば、常に人々にPinDropを実装してもらいたいと思います。正味の負のIMOになります。

IIRCの人々が実際にPinを気にするメソッドをVecに実装したいので、Vecを選びました。つまり、Unpinを無条件に実装することはできませんでした。

うーん、私はそれが好きではないと思います。 Boxが無条件にUnpin場合、 Vecは同じである必要があると思います。 2つのタイプは通常、所有権がほぼ同等です。

また、 drop保証にも注意する必要があります。 たとえば、 Vec::drainは、パニックの場合に物事が漏洩する可能性があります。

これは、コピーの代わりにPinProjectionを使用しただけで、ほぼ同じように見えます

ああ、今私はあなたの質問を理解しています。 私の提案にはそのような特性がなかったので、実際にはPinProjections自動導出について話していませんでしたが、実際、私の提案の1つの結果は、 Dropを追加することは重大な変更であるということです。パブリックフィールドがあります。

実際に実行できるのは、Dropの実装とPinProjectionsの派生を同時に行うことだけですが、可能であれば、とにかくPinDropを実装してもらいたいので、正味の負のIMOになります。

それが実際のポイントでした。 これらすべてのピン留めについて気にする必要のある人が少なければ少ないほどよい。

明確化の質問：あなたと@withoutboatsの提案では、 PinDropはlangアイテムであり、コンパイラによってDrop代わりとして扱われますか、それともderive(PinProjections)によって使用される特性だけですか？ Drop ？

また、落下保証にも注意する必要があります。 たとえば、Vec :: drainはパニックの場合に物が漏れる原因となる可能性があります。

まあ、それは本当ですが、実際にはメモリの割り当てを解除しませんよね？ 明確にするために、 VecがUnpin無条件に実装することを実際に好むのは、人々がPinDropに切り替えるのが簡単になるからですが、確かに話し合いがありましたバッキング要素に固定できるようにすることに関する固定に関する議論の一部。 固定されているフィールドについて話し始めると、常にVecをBox<[T]>に変換して固定できるとは限らないことが明らかになります。そのため、実際には（明らかにあなたも追加できるものの、その点PinVecの代わりに入力しVecなどのために行われた、タイプをBox ）。

それが実際のポイントでした。 これらすべてのピン留めについて気にする必要のある人が少なければ少ないほどよい。

うーん、私の観点からは、最初はそうですが、長期的には、特にタイプが実際に#[derive(PinProjections)]に悩まされている場合は、できるだけ多くの人をデフォルトのPinDropに移行したいと思います。 #[derive(PinProjections)] （これも、タイプがUnpin場合、目的を問わず必要ありません。おそらく、生成されたコードなどでのみ発生します）。 次に（おそらく&pinがしばらくの間その言語で使用されていた後）、 DropをDeprecatedDropなどに切り替えるエポック変更を行うことができます。 Unpinタイプの場合、タイプシグネチャを&mutから&mut pinするだけでほぼすべてが解決されるため、これは実際には必要ないかもしれません。

明確化の質問：あなたと@withoutboatsの提案では、PinDropはlangアイテムであり、コンパイラによってDropの代わりとして扱われますか、それとも、derive（PinProjections）がDropを実装するために使用する特性ですか？

前者。

このDropの議論全体は、元のRFCに代わってかなり徹底的な見落としのように思われます。 これを議論するために新しいRFCを開くことは価値がありますか？ 懸念事項が何であるか、他の懸念事項よりも有害であるか、当初考えていたよりもどれだけ多くの機械を言語に追加する必要があるか、どの程度の破損が予想されるか（および最悪の場合と最良の場合のシナリオ、Dropに成功するものに移行する方法、これらすべてをパントし、他の手段（https：など）で2018年の目標を達成できるかどうかをエディションで軽減できます。 //github.com/rust-lang/rfcs/pull/2418は、安定化をブロックしないように、すべてのパブリックAPIからPinを非表示にすることを提案しています）。

@bstrie大きな懸念事項は1つだけだと思いますが、それはかなり重要な問題です。 RFCは、最終的な&pin mutタイプが、ある時点でこの種のコードを安全にする可能性があることを理解して承認されました。

struct Foo<T> { foo : T }

fn bar<T>(x: &pin mut Foo<T>) -> &pin mut T {
  &pin mut x.foo
}

この種のコードが安全であることが重要です。実際には、固定された参照は安全なコードでは実際には構成できないため、たとえば、futureコンビネータを実装するには、 unsafe使用する必要があります。 当時、 unsafeの使用はほとんどの場合解除できると考えられていたので、大したことではありませんでした。

残念ながら、これが安全かどうかは、 FooのDrop実装に依存します。 したがって、安全なフィールドプロジェクションをサポートしたい場合（言語機能、カスタム#[derive] 、またはその他のメカニズムを介して）、そのような悪いDrop実装ができることを保証できなければなりません。起こりません。

最適に機能すると思われる代替方法では、上記のコードをunsafe使用せずに（構造の上に#[derive(PinProjections)]を追加するだけで）機能させることができ、既存のコードを壊すこともありません。 。 Pinがすでに安定している場合でも、逆方向に追加できます。また、純粋なライブラリとして追加することもできます（人間工学的に深刻な打撃を受けます）。 アクセサを生成するための#[derive]マクロと、最終的な&pinネイティブ参照型の両方と互換性があります。 少なくとも1つの新しいトレイト（およびDropの固定バージョンの実装方法によっては2つ）を追加する必要がありますが、 where句またはトレイトオブジェクトのどこにも表示される必要はありません。 dropの新しいバージョンは、現在Drop実装があり、ピンプロジェクションをオプトインしたいタイプにのみ実装する必要があります。

ソリューションに多くの欠点がないように見えるからといって、それが実質的な変更ではないことを意味するわけではないので、この提案のRFCをほぼ確実に作成すると思います（ @withoutboatsと私は電話でこれを行うことについて話し合いました） 。 完全な下位互換性があるため、単独でパントするのは問題ありません。 ただし、個人的には、他の場所での固定を取り除くよりも、この変更をプッシュする方が理にかなっていると思います。

パブリックAPIのPinMutに関するほとんどの人の懸念は、 unsafeまたはUnpin境界をどこでもスレッド化する必要があるということです。この提案は、その問題を解決します。 rust-lang / rfcs＃2418で説明されている代替案は、ピン留め（パブリックAPIやドキュメントに表示される他のさまざまな特性の急増を伴う）の処理を回避したい方法の実際のメカニズムの両方で、はるかに物議を醸しているようです。ソリューションの全体的な複雑さにおいて。 確かに、ピン留めが完全に解決されたとしても、そのRFCで十分に解決されたとは思わない質問がたくさんあると思います。したがって、RFCが安全なピンプロジェクションを追加することになる可能性は少なくとも十分あると思います。その前に受け入れられています。

確かにピン留めは初期の段階ですが（安定化が早すぎるように思われると不満を言っていました）、安全なフィールドプロジェクションの欠如が、人々がピン留めをまったく使用しないようにする最後の大きな要因だと思います。 。 完全を期すために、ピン留めで人々が提起するすべての問題、提案された解決策、および解決策が既存のPinタイプと下位互換性があるかどうかを以下に示します（非常に大まかな、偏った順序で物議を醸す私はこの問題が現時点であると認識しています）：

• これ（投影フィールドを安全なコードで実行させることはできますか？） 今後のRFCによって解決される予定です（可能な実装戦略、および検討した他の代替案と、それらを破棄する必要がある理由が詳しく説明されます）。 提案された解像度のすべてのバリエーションには、下位互換性があります。

• !Unpinタイプの値を手動デストラクタで固定することは、追加の保証（デストラクタが呼び出されるまで値のバッキングメモリが無効にならないこと）、別名「侵入型コレクションの変更」を意味する必要がありますか？

  提案されたスタック固定APIを壊す可能性があるため、まだ解決されていません。 この保証を保持するスタックピン留めAPIを非同期/待機で動作させることができれば、ほとんどの利害関係者はこれを受け入れても構わないと思っているようです（IIRCの誰かがすでにジェネレーターを使用してこれを解決しようとしましたが、ラストICEしました）。

  古い保証との下位互換性はありません。 今のところ保証を実施するために安全でないコードを要求することは、考えられる両方の結果と互換性がありますが、安全でないコードが正確さのために実施されていることに依存することが許可されていない場合に限ります。 したがって、これには、ピン留めが安定する前に、いずれかの方法で解決する必要があります。

  幸い、 Futureのピン留めのユーザーは、スタックピン留めAPIの形状に加えて、これを無視できます。 クロージャーベースのスタックピン留めAPIはどちらの解像度とも互換性があるため、async / awaitを使用していないFutureユーザーは、これが決定されるのを待たずに、クロージャーベースのAPIを今日使用できます。 この決定は、他の目的（侵入的なコレクションなど）にピン留めを使用したい人に最も影響を与えます。

• 生のポインタは無条件にUnpinますか？ まだ解決されていません（私はそれを提案したのは私だけだと思います、そして私はまだそれについてほぼ50-50です）。 下位互換性はありません。 私はこれを主にその理由で物議を醸すものとしてマークしています。
• Vecような標準ライブラリタイプを無条件にUnpinにする必要がありますか、それともPinフィールドアクセサーを追加する必要がありますか？ まだ解決されておらず、ケースバイケースで解決が必要な場合があります。 任意の安全なラッパータイプについて、アクセサーを追加するか、タイプを無条件にUnpinは、下位互換性があります。
• PinMut::derefを削除する必要がありますか？ それを維持することの利点が欠点をはるかに上回っているように見えるので、答えは基本的に「いいえ」のようです。元々人々にそれを欲しがらせた場合（具体的にはPin<RefCell<T>> ）の回避策があるようです。 それを変更すると、後方互換性がなくなります。
• （ドロップの問題を無視して）短期的にフィールドアクセサーをどのように提供する必要がありますか？ まだ解決されていません。これまでに提示された2つのオプションは、 https://github.com/pythonesque/pintrusiveです。 ドロップの変更後、これは純粋にライブラリコード内のマクロで適切に実行できるため、解像度には完全な下位互換性があります。
• 長期的にフィールドアクセサーをどのように提供する必要がありますか（つまり、カスタムの&mut pinおよび&pin Rustタイプが必要ですか？再借用はどのように機能する必要がありますか？）。 まだ解決されていませんが、他のすべての提案された変更と下位互換性があり（私の知る限り）、明らかに無期限にパントされる可能性があります。
• 安全な参照のようなタイプは無条件にUnpinますか？ 解決されたようです（はい、そうすべきです）。 解像度には完全な下位互換性があります。
• フィールドアクセサーを実現可能にするために、一意のPin Pinタイプに加えて、共有の&Pin 、への参照であるため、 PinをPinMutし、共有ケースにPinタイプを追加することPinからPinMut ）はすでに行われており、これはすでに効果的に受け入れられていると確信しています。

私はそれをほぼカバーしていると思います。 ご覧のとおり、今日ピン留めが安定していても、それらすべて（生のポインターとderefの決定を除いて、後者はこの時点で大部分が解決されているようです）には下位互換性のあるパスがあります。 さらに重要なことに、フィールドプロジェクションを解決できるという事実は、APIで固定型を使用することが、後で後悔する決定になる運命にないことを意味します。

上記の質問に加えて、はるかに基本的な方法でピン留めを再考することを目的とした他の提案がありました。 二人は私が最もよく理解させるために@comex案だと思うことを!Unpin種類!DynSized 、そしてsteven099（内部で、申し訳ありませんが、私はGitHubの名を知らない）への提案を内部を動かせないようにする新しいサイズのないPinnedラッパータイプがあります（ZSTラッパーのようなものです）。

!DynSizedオプションは、不透明（OPAQUE）型を処理するためにすでに必要になる可能性があるという利点がある（Rustがすでに同様の特性を利用できるという意味で）かなり保守的な機能です。 この意味で、提案されているDropへの変更よりも侵襲性が低い可能性があります。 また、高い利点もあります。 !Unpinタイプは!DynSizedになるため、 Dropの問題は自動的に解決されるため、そこから移動することはできません。 これにより、 &mut Tと&T自動的にPinMutとPinとして機能し、 Tが!DynSized場合は、次のようになります。 &mut T動作するタイプとメソッドの固定バージョンを急増させる必要はありません（必要のないときにDynSizedバインドを必要としないように修正された場合）。 ）。

主な欠点（ ?Traitに関する通常の懸念を除く）は、 !Unpinタイプを移動できないことであるように思われます。これは、現在ピン留めされているタイプの状況とはまったく異なります。 これは、参照を使用せずに2つの固定タイプを作成することは実際には不可能であり（とにかく、私が知る限り）、これに対する解決策が提案されているかどうかはわかりません。 IIRCこれは、 &move提案と一緒に機能することを目的としていましたが、その意図されたセマンティクスが何であるかはわかりません。 また、不透明（OPAQUE）型に依存しているため、（提案から）安全なフィールドプロジェクションを使用する方法もわかりません。 それを使用するには、一般的に多くの安全でないコードを使用する必要があるようです。

サイズなしのPinned<T>タイプは、精神的には多少似ていますが、タイプをZSTでラップして動かせないようにすることで、上記の問題を回避したいと考えています（効果的にサイズなしで動作します）。 現時点では、Rustにはこれに匹敵するものはありません。 PhantomDataは実際には型のインスタンスが含まれておらず、他の動的なサイズの型はファットポインターを生成し、移動を許可します（ size_of_val依存するAPIを使用） ?DynSizedが修正することを意図したものであるため、この提案はおそらくその特性に再び便乗します）。 安全な予測を許可した場合、この提案が実際にDrop問題を修正するようには思えません。また、 Derefと互換性がないように思われるため、 Pinよりも優れています。

この保証を保持するスタックピン留めAPIを非同期で動作させることができれば、ほとんどの利害関係者はこれを受け入れても構わないと思っているようです（IIRC誰かがすでにジェネレーターを使用してこれを解決しようとしましたが、ラストICEしました）

参考までに、これはおそらくhttps://github.com/rust-lang/rust/issues/49537を参照していこの試みからのものです。 ただし、ICEが解決されたとしても、そこでの存続期間が機能するかどうかはわかりません。

提案されたスタック固定APIを壊す可能性があるため、まだ解決されていません。 この保証を保持するスタックピン留めAPIを非同期/待機で動作させることができれば、ほとんどの利害関係者はこれを受け入れても構わないと思っているようです（IIRCの誰かがすでにジェネレーターを使用してこれを解決しようとしましたが、ラストICEしました）。

クロージャーベースのスタックピン留めAPIは、これに対する解決策であり、より人間工学的でコンパイラーによってチェックされる将来の手段（ &pinが言語プリミティブになると）があります。 @cramertjによって提案されたこのマクロベースのソリューションもあります。

生のポインタを無条件に固定解除する必要がありますか？ [...]下位互換性はありません。 私はこれを主にその理由で物議を醸すものとしてマークしています。

impl Unpin for Vec<T>追加には下位互換性があるのに、生のポインターに対して同じことを行うのはなぜそうではないと思うのですか？

主な欠点（？Traitに関する通常の懸念に加えて）は、！Unpinタイプを移動できないことであるように思われます。これは、現在のピン留めタイプの状況とはまったく異なります。 これは、参照を使用せずに2つの固定タイプを作成することは実際には不可能であり（とにかく、私が知る限り）、これに対する解決策が提案されているかどうかはわかりません。 IIRCこれは、＆move提案と一緒に機能することを目的としていましたが、その意図されたセマンティクスが何であるかはわかりません。

さて、 @ steven099のバリアント提案（私が好んだ）では、ほとんどのユーザーは（今のところ） Pinned<T>使用します。これには、値でTれますが、 !Sized （そして多分!DynSized ;特性階層の正確な設計はバイクシェディングに開かれています）。 これは実際には、 &'a mut Pinned<T>がPin<'a, T>代わりになることを除いて、既存の提案と非常によく似ています。 ただし、 &mut T （ T: ?Sized ）で一般的な現在および将来のコードとの互換性が高く、真のネイティブの不動型の将来の設計との下位互換性が高くなります。 Pinnedます。

詳細については、 Pinnedは次のようになります。

extern { type MakeMeUnsized; }

#[fundamental]
#[repr(C)]
struct Pinned<T> {
    val: T,
    _make_me_unsized: MakeMeUnsized,
}

通常、 Pinned<T>直接作成することはありません。 代わりに、 Foo<T>からFoo<Pinned<T>>にキャストできます。ここで、 Fooは、コンテンツが移動しないことを保証するスマートポインターです。

// This would actually be a method on Box:
fn pin_box<T>(b: Box<T>) -> Box<Pinned<T>> {
    unsafe { transmute(b) }
}

（おそらくマクロに基づくスタック固定APIも存在する可能性がありますが、実装は少し複雑です。）

この例では、 FakeGeneratorはコンパイラーによって生成されたジェネレータータイプを表します。

enum FakeGenerator {
    Initial,
    SelfBorrowing { val: i32, reference_to_val: *const i32 },
    Finished,
}

FakeGenerator値が固定されると、ユーザーコードは値（ foo: FakeGenerator ）または参照（ foo: &mut FakeGenerator ）で直接アクセスできなくなります。後者はswapまたはreplace使用を許可します。 代わりに、ユーザーコードは、たとえば&mut Pinned<FakeGenerator>と直接連携します。 繰り返しますが、これは既存の提案のPinMut<'a, FakeGenerator>のルールと非常によく似ています。 しかし、より良い構成可能性の例として、コンパイラーによって生成されたimplは、 Pin<Self>を取る新しい特性を必要とするのではなく、既存のIterator特性を使用できます。

impl Iterator for Pinned<FakeGenerator> {
    type Item = i32;
    fn next(&mut self) -> Option<Self::Item> {
        /* elided */
    }
}

一方、初期構築では、固定される前に非自己借用状態のみにアクセスできることを保証する限り、 FakeGenerator値を直接配布して、それらを移動できるようにすることができます。

impl FakeGenerator {
    fn new() -> Self { FakeGenerator::Initial }
}

したがって、2つのFakeGeneratorを値で構成する場合、構築は簡単です。

struct TwoGenerators {
    a: FakeGenerator,
    b: FakeGenerator,
}

impl TwoGenerators {
    fn new() -> Self {
        TwoGenerators {
            a: FakeGenerator::new(),
            b: FakeGenerator::new(),
        }
    }
}

次に、 TwoGeneratorsオブジェクト全体を固定できます。

let generator = pin_box(Box::new(TwoGenerators::new()));

しかし、あなたが言ったように、フィールドプロジェクションが必要です： &mut Pinned<TwoGenerators>から&mut Pinned<FakeGenerator> （ aまたはbいずれかにアクセスする）。 ここでも、これは既存のPinデザインと非常によく似ています。 今のところ、マクロを使用してアクセサーを生成します。

// Some helper methods:
impl<T> Pinned<T> {
    // Only call this if you can promise not to call swap/replace/etc.:
    unsafe fn unpin_mut(&mut self) -> &mut T {
        &mut self.val
    }
    // Only call this if you promise not to call swap/replace/etc. on the
    // *input*, after the borrow is over.
    unsafe fn with_mut(ptr: &mut T) -> &mut Pinned<T> {
        &mut *(ptr as *mut T as *mut Pinned<T>)
    }
}

// These accessors would be macro-generated:
impl Pinned<TwoGenerators> {
    fn a(&mut self) -> &mut Pinned<FakeGenerator> {
        unsafe { Pinned::with_mut(&mut self.unpin_mut().a) }
    }
    fn b(&mut self) -> &mut Pinned<FakeGenerator> {
        unsafe { Pinned::with_mut(&mut self.unpin_mut().b) }
    }
}

ただし、既存の設計と同様に、マクロでは、ユーザーがTwoGeneratorsに対してDropを実装できないようにする必要があります。 一方、理想的には、コンパイラーはimpl Drop for Pinned<TwoGenerators>を許可します。 現在、「ドロップの実装は特殊化できません」というエラーでこれを拒否していますが、変更される可能性があります。 IMOこれは、新しい特性を必要としないため、 PinDropよりも少し良いでしょう。

現在、将来の拡張として、原則として、コンパイラーはネイティブフィールド構文を使用してPinned<Struct>からPinned<Field>に移行することをサポートできます。これは、コンパイラーがネイティブ&pin T追加できるという既存の設計の下での提案に似ています。

しかし、私の理想的な「エンドゲーム」はそれではなく、コンパイラーがいつか実存的な存続期間を含む「ネイティブ」の不動の型をサポートする、より劇的な（そして実装がより複雑な）何かです。 何かのようなもの：

struct SelfReferential {
    foo: i32,
    ref_to_foo: &'foo i32,
}

これらのタイプは、 !SizedなどでPinned<T>ように動作します。[1]ただし、 Pinnedとは異なり、初期の可動状態は必要ありません。 代わりに、「保証されたコピーの省略」に基づいて機能します。コンパイラーは、関数の戻り値、構造体リテラル、およびその他のさまざまな場所で不動の型を使用できますが、内部でそれらが適切に構築されることを保証します。 したがって、次のように書くことができるだけではありません。

let sr = SelfReferential { foo: 5, ref_to_foo: &sr.foo };

（これはすでにちょっとすることができ

fn make_self_referential() -> SelfReferential {
    let sr = SelfReferential { foo: 5, ref_to_foo: &sr.foo };
    sr
}

または

let sr: Box<SelfReferential> = box SelfReferential { foo: 5, ref_to_foo: &sr.foo };

もちろん、上記は機能がどのように見えるかについての非常に大まかなスケッチにすぎません。 私が使用した構文には問題があり、構文は機能の設計に伴う多くの複雑さの中で最も少ないものになります。 （とはいえ、私はそれについて十分に考えたので、複雑さを解決できるとかなり確信しています。それは、うまくいかない単なる一貫性のないアイデアではありません。）

現在のところ、既存のPinデザインの代わりに!DynSizedっぽいデザインを使用する動機の一部として言及しているだけです。 &'a Pinned<T>は、ポインタータイプの組み合わせ爆発を回避するため、すでにPin<'a, T>よりも優れていると思います。 しかし、それは同じ問題のいくつかを継承します：

1. 基本的に、初期の可動状態がないタイプはサポートしていません。
2. ノイズが多く、混乱を招き（同じ型への固定参照と非固定参照の違いを説明するのは難しい）、不動の型は二流のように感じられます。 動かせない自己参照型は、本質的に有用であると同時に、自己参照値を簡単かつ一般的に作成できる他の言語から来た人々にとってRustの見栄えを良くするために、一流であると感じてもらいたいです。

将来、私が想像しているのは、ネイティブの不動型が両方の問題を解決し、ほとんどのコードで「ピン」という単語を使用する必要がなくなることです。 （ PinnedはまだいくつかのユースケースがPinは「まだ固定されていない」状態を、それを使用するすべての特性の設計に分離します。 そして、組み込みの&pinは、それを言語に焼き付けます。

とにかく、ここに上記のPinnedデザインの遊び場のリンクがあります。

[1] ...静的なサイズであるが移動可能である場合と移動できない場合があるタイプの場合、新しい特性ReallySized （あまり愚かな名前ではない）が必要になる場合があります。 サイズ変更されていない右辺値がサポートされているため、現在Sized引数をとる多くの関数は、サイズが変更されていないが移動可能な関数でも同様に機能する可能性があるため、とにかくここでチャーンが発生します。 既存の関数の境界と、将来の関数に使用する境界の推奨事項の両方を変更します。 将来のエディションで関数ジェネリックのデフォルト（暗黙）のバインドを変更する価値があるかもしれないと私は主張しますが、これにはいくつかの欠点があります。

[編集：修正されたコード例]

@RalfJung

クロージャーベースのスタックピン留めAPIは、これに対する解決策であり、より人間工学的でコンパイラーによってチェックされる将来の手段（＆pinが言語プリミティブになると）があります。 @cramertjによって提案されたこのマクロベースのソリューションもあります。

クロージャベースのものは、クロージャ内から譲歩できないため、async / awaitでは正しく機能しないと思います。 ただし、マクロベースのものは興味深いものです。 それが本当に安全なら、それはかなり独創的です。 スコープのドロップの1つでパニックが発生すると、他のリークが発生する可能性があるため、最初はうまくいくとは思いませんでしたが、MIRで修正されたようです。

また、「メモリの割り当てが解除される前に実行されるデストラクタ」の保証と、固定されたフィールドを投影する機能との間の相互作用についても確信が持てませんでした。 トップレベルのドロップがパニックになった場合、値に投影された固定フィールドではドロップが実行されないと思っていました。 ただし、Rustプレイグラウンドでは、トップレベルのタイプがパニックになった後でも、このタイプのフィールドのドロップがとにかく実行されているように見えます。これは非常にエキサイティングです。 その保証は実際にどこかに文書化されていますか？ スタックのピン留めがピンプロジェクションで機能する場合は必要と思われます（または、PinDropが常にパニックで中断するなど、より重いもので、DropとPinDropの機能に違いが生じるため、望ましくないようです）。

なぜVecにimplUnpinを追加すると思いますか下位互換性はありますが、生のポインタに対して同じことを行うことはできませんか？

私はあなたのポイントを理解しています：誰かが所有するVec<T>フィールドからの自動!Unpin実装に依存し、ピン留めが特定の!Unpin Tに対して推移的であると想定した独自のアクセサーを実装している可能性がありますPinMut<Vec<T>>が実際にPinMut<T>を取得するための安全な方法を提供していないのは事実ですが、安全でないコードはPinMut::derefを悪用して、生のポインターを取得し、ポインタは安定しています。 したがって、これは、安全でないコードが!UnpinがVec （またはその他）を推移することに依存しない場合にのみ下位互換性がある別の状況だと思います。 しかし、否定的な推論へのそのような大きな依存は、とにかく私には怪しいようです。 !Unpinであり、 Tでないことを確認したい場合は、いつでもPhantomData<T>追加できます（この引数は生のポインターにも当てはまると思います）。 「タイプが明示的にオプトアウトするか、ドキュメントでこれが信頼できると宣言されていない限り、標準ライブラリのタイプが安全でないコードで！Unpinであると想定するのはUBです」のような包括的なステートメントでおそらく十分でしょう。

ただし、マクロベースのものは興味深いものです。 それが本当に安全なら、それはかなり独創的です。 スコープのドロップの1つでパニックが発生すると、他のリークが発生する可能性があるため、最初はうまくいくとは思いませんでしたが、MIRで修正されたようです。

ドロップ中にパニックが残りのローカル変数のドロップをスキップすることにつながる場合、それはMIRのバグになります。 「通常のドロップ」から「巻き戻しドロップ」に切り替えるだけです。 その後、別のパニックがプログラムを中止します。

@RalfJung

ドロップ中にパニックが残りのローカル変数のドロップをスキップすることにつながる場合、それはMIRのバグになります。 「通常のドロップ」から「巻き戻しドロップ」に切り替えるだけです。 その後、別のパニックがプログラムを中止します。

ドロップされる構造内の他のフィールドは、このコンテキストではローカル変数と見なされますか？ これは、ユーザー向けのドキュメントからははっきりしません（実際、これはあなたが話している保証全体に当てはまります。実際には、問題追跡システムから修正する必要があるバグと見なされていることがわかりました）。

@comex

Pinned （あなたが提案しているもの）についてのことは、私たちがそれを実装したいのであれば（Rustがすべての機能を備えていれば）、それを作るためにこれ以上のことをする必要はないと思うということです既存のコードとの下位互換性：

type PinMut<'a, T> = &'a mut Pinned<T>;
type Pin<'a, T> = &'a Pinned<T>;

（ PinからPinnedへのderef実装も提案されたと思います）。 これがうまくいかないと思われる場所を調べることは有益です。 例えば：

impl Drop for Pinned<TwoGenerators>

PinMutでは（少なくとも、簡単ではありませんが）機能しません。 Pinned型が構築されたときに、これがDropをTwoGenerators自体に置き換えると仮定しても（これがどのように機能するかはわかりませんか？）、Rustはまだ機能しませんフィールドは値によって保持されるだけなので、投影されたフィールドに対してコンストラクターのPinnedバージョンを呼び出すことを知っています。 固定されたバージョンのデストラクタが存在する場合は常に使用されていた場合、これはPinDropと実質的に同じですが、構文がおかしいだけで、どのように優れているかわかりません。

ただし、値がPinnedに基づいているかどうかを再帰的に分析することにより、デストラクタの選択を検討したくなるでしょう。 値によるトレイトオブジェクトを許可したい場合、コンパイル時にPinned<T>ドロップを使用するかTドロップを使用するかを決定できることに必ずしも依存できないことに注意してください。 このような場合、 Pinnedバージョン用に別のvtableエントリがある可能性があると考えていると思いますか？ このアイデアは私にとって一種の興味をそそるものです。 確かにかなりのコンパイラサポートが必要です（提案されたPinDropよりもはるかに多い）が、いくつかの点で全体的に優れている可能性があります。

ただし、スレッドを読み直すと、他にも問題があることを思い出します。固定された型のderef実装は、 Pinned<T>では実際にはうまく機能しません（これは、 deref実装が原因であると思われます） PinMutは何らかの形で論理的に間違っているため、問題が発生し続けますが、無条件に多数の型を作成しない限り、その利便性を考えると、それを失うことを正当化するのは非常に困難です。 UnpinとにかくRefCell例は、 Pinned::derefが存在する場合、既存のタイプで動的にピン留めを強制することさえできないことを意味するため、かなり厄介だと思います（わかりません）専門化で十分な場合）。 これは、さらに我々が続ければことを示唆しているderef実装を、私たちは、ほぼ同じくらいとAPIの表面を複製終わる必要がありますPinned我々がそうであるようにPin ; それを保持しないと、 Pinned<T>は驚くほど使いにくくなります。 また、（スレッドで指摘されているように） ?DynSized ?Move別にBox<Pinned<T>>が機能するようには見えません。

これはすべて良い考えかもしれませんが、現在のRustのコンテキストでは、特に現在のRustのメソッドに?Move境界がないことを考えると、全体が魅力的ではないように見えます（不足していることを意味します）。タイプがUnpinでない限り、 derefは本当に痛いです。その場合、 Pinnedは利点がありません）。 所有するプロパティを固定することで、実際に何が起こっているのかをより厳密にモデル化しているのではないかと思います。これにより、 PinMut::derefようなアドホックな決定を回避することが難しくなり、（主観的にはとにかく）はるかに快適なインターフェイスになります。 、しかしそれはそうするために多くの言語機構を追加し、あなたがそれのどれもが特に有用であると思うようには思えません（あなたが提案しているネイティブの動かせないタイプと比較して）。 また、完全に逆方向に取得できなかったことがわかったかどうかもわかりません-互換性がある（ほとんどの場合、ピンのステータスに応じて別のドロップ実装を呼び出す）ことは、実行できたとしても実際にはそれほど便利です（おそらく、タイプが固定されていることがわかっている場合は、デストラクタで分岐することがありますか？）。 したがって、現時点でPinMut提案を変更する価値があるかどうかはわかりません。 しかし、おそらく私はいくつかの本当に説得力のある具体的なユースケースを見逃しています。

Pinned （あなたが提案しているもの）についてのことは、私たちがそれを実装したいのであれば（Rustがすべての機能を備えていれば）、それを作るためにこれ以上のことをする必要はないと思うということです既存のコードとの下位互換性：

type PinMut<'a, T> = &'a mut Pinned<T>;
type Pin<'a, T> = &'a Pinned<T>;

まず第一に、 Pinned自体は、それが「機能」の意味である場合、最小限またはまったくのコンパイラサポートを必要としません。 DynSizedや関連する特性など、ライブラリの設計を意味する場合、それは有効ですが…

たとえば、 Pin<'a, T>と&'a T両方に同じ特性を実装しようとすると、突然競合する可能性があるため、提案した内容には下位互換性がありません。

より一般的には、APIの設計には大きな違いがあります。 Pin場合、不動の型によって暗黙的に示されると予想される特性は、メソッドがPinMut<Self>を取る必要があり、不動の型への参照を取得するジェネリック関数はfn foo<T>(p: PinMut<T>)ように見える必要があります。一方、 Pinned設計では、 Pinned<MyStruct>特性を実装できるため、ほとんどの場合、新しい特性の必要性が回避されます。 したがって：

1. 不動の型は、メソッドが&selfまたは&mut self取る既存の特性と互換性がありません。たとえば、ジェネレーターはIterator実装できませんPinMut<Self>取る新しい特性の束が必要になります。 コースを変更してPinMut<T>を&mut Pinned<T>エイリアスにした場合、戻ってこれらの重複する特性をすべて非推奨にすることができますが、それはかなりばかげています。 そもそも重複が必要ない方がいいです。

2. 一方、新しく設計された、またはジェネレータ固有のトレイトは、おそらくPinMut<Self>を唯一のオプションとして使用しますが、トレイトを実装したいが動かせず、必要のないタイプにはノイズが追加されます。固定されます。 （具体的には、 Self: Unpin想定すると、発信者は&mut selfからPinMut<Self> PinMut::newに移動するためにPin<T>が&mut Pinned<T>エイリアスの場合、そのノイズを取り除く方法はありません。 そして、私が想像している将来のネイティブの不動型は、可動型と同じ状況になり、常に固定されていると見なされるときに、不必要にPinnedでラップする必要があります。

残りの投稿には2回目の投稿で返信します。

Drop

Dropについてあなたが言っていることに少し混乱していますが、 PinMutとの下位互換性を持たせようとしている限り、それについては考えません。それは良いアプローチではないと思うからです。

最善のアプローチは、 TwoGeneratorsような構造体がある場合、2つのオプションがあることだと思います。

1. TwoGeneratorsまたはPinned<TwoGenerators>いずれにも手動のDrop implはありません。
2. Pinned<TwoGenerators>に対してDropを実装します; 一方、アクセサを提供する同じマクロは、 TwoGenerators自体に対してDrop implを生成します。これは、単に自分自身を&mut Pinned<TwoGenerators>キャストし、それをドロップします。 （これは安全です： &mut Tを&mut Pinned<T>にキャストするために必要な不変条件は、借用が終了した後、 Drop場合、 T移動しないことです。 Drop 、その値に対して作成される最後の借用があります。）

2つのオプションがある唯一の理由は、前述のように、構造体にDropを実装させたくない場合があるためです。これは、構造体を実装しない構造体は、借用チェッカーによってより緩く扱われるためです。

ピン留めされた状態とピン留めされていない状態に対して実際に別々のデストラクタが必要な理由がわかりません。そのため、vtableを使用してそれらを区別するためのトリックを行う必要はありません。

RefCell

Pinned::derefは存在すべきではないと思います。 安全なマクロ生成フィールドアクセサーで十分です。 それが「驚くほど使いにくい」のかわかりません。 ネイティブフィールド構文を使用できるよりも少し劣りますが、いつかネイティブの不動の構造体によって修正される予定です。 とにかく、使いにくい場合は、同じ問題がPin当てはまります。

これにより、 RefCellの問題が回避されます。

特に、現在のRustには基本的に?Move境界がないメソッドがないと考える場合（つまり、derefがないと本当に害があります[..]）。

それどころか、 ?Sizedバインドがあるものはすべて、暗黙的に?Moveます。

一般に、 ?Sizedバインドされたコードで移動可能性を想定することは不可能であるため、これは理にかなっています。 唯一の例外は、 size_of_valを呼び出し、次にmemcpyのバイト数を呼び出す安全でないコードです。そのため、 size_of_valが不動の型に対してパニックになる（そして新しい関数のために非推奨になる）ハックが必要です適切な範囲で）。

Dropについてあなたが言っていることに少し混乱していますが、PinMutとの下位互換性を持たせようとしている限り、それは良いアプローチではないと思うので、それについては考えません。 。

何かがPinMutと下位互換性がない場合、それにPinned<T> （現在のRustでは機能しません）に実装することを除いて、すべての点でPinDropと機能的に同じです。 個人的には、 Drop専門化することはPinDropは、他の提案からほとんど分離できると思います。

とにかく、使いにくい場合は、同じ問題がピンにも当てはまります。

もちろん、 PinMut::derefを削除したいのであれば、 RefCellようなタイプでもうまく構成できます。 違いは、私たちが持つソリューション一緒に玉石まだできることPinMutサポートしながら、 derefでない仕事に思われる、 Pinned 。 deref実装を取り除けば、 Pinnedが意味のある利点を提供することに同意する可能性がはるかに高いと思います。

しかし、 derefがないことが実際には小さな問題であることに同意するかどうかは本当にわかりません。たとえば、現在の状態では、 &Pinned<Vec<T>>何もできないというT: !Unpinであり、基本的にすべての既存のライブラリタイプに同じことが当てはまります。 これは、 Unpin動作方法に起因する問題であり、特定の種類の参照ではありません。 エコシステムは、 impl Deref for Pinned<Vec<T>> { type Target = Pinned<[T]>; }か何かに沿って物事を行うことを集合的に決定する必要があります。これを機能させることができれば、 impl PinDeref<Vec<T>>よりも望ましいと思いますが、それはderefない世界。 derefある世界でderef 、ほとんどすべてのライブラリがピン関連のアクセサなしで逃げることができ、それでも!Unpinタイプを半分まともなサポートがあります。

それどころか、「サイズ制限」を持つものはすべて暗黙的に「移動」されます。

そうそう、それは良い点です。 残念ながら、Rustコードの全体は、デフォルトではないため、 !Sizedバインドされたタイプでは機能しませんが、少なくとも一部は機能します。 サイズなしの値で実行できることのほとんどは、それらのメソッド（スライスや特性オブジェクトなど）で&または&mutメソッドを呼び出すことであり、どちらも呼び出されないため、それほど魅力的な利点ではないと思います。 Pinned::derefが必要ないので、（ Unpinタイプを除いて）あなたの提案の下でこれを行うことができます。 たぶん、一般的なケースは、 #[derive]実装で、 Pinned<T>などの個別のインスタンスを生成することで対処できますか？

Drop

個人的には、Dropを専門化することは非常に疑わしい前例を設定し、ピン留めとは関係のない理由でほぼ確実に望ましくないと思います。したがって、これを本質的な利点とは見なしません。 いずれにせよ、PinDropは他の提案からほとんど切り離すことができると思います。

これは分離可能であることに同意しますが、疑わしいとは思いません。 少なくとも…あなたが言ったことは正しいです、それは専門化の一形態です。 Drop親ブランケットの実装を文字通り特殊化するわけではありませんが、コンパイラが生成するドロップグルーは、実装されている場合にのみDrop呼び出すことで、特殊化と同等の処理を実行します。 'userland'の実装は次のようになります（手動でdrop呼び出すことができないという事実を無視します）。

trait DropIfImplemented {
    fn maybe_drop(&mut self);
}
impl<T: ?Sized> DropIfImplemented for T {
    default fn maybe_drop(&mut self) {}
}
impl<T: ?Sized + Drop> DropIfImplemented for T {
    fn maybe_drop(&mut self) { self.drop() }
}

したがって、現在「特殊化された」ドロップimplを記述できない理由は、特殊化自体が現在不健全であるのと同じ理由であると思います。つまり、trans（ライフタイムパラメーターを消去する）とtypeck（そうでない）の間の一貫性がありません。 言い換えると、たとえばimpl Drop for Foo<'static>と書くことができれば、codegenは2つのタイプが同一であると想定しているため、実際にはFoo<'static>だけでなく、任意のFoo<'a>に対して呼び出されます。

良いニュースは、おそらくご存知のように、特殊なimplを制限して、そのタイプのインコヒーレンスを作成できないようにする方法を見つけようとする試みがあったことです。 そして、スペシャライゼーションは最終的にはそのような制限付きで出荷されると予想されます。 それが起こったら、同じルールをDrop implsに適用できなかった理由はわかりません。そして、言語を可能な限り一貫性のあるものにするために、そうすべきです。

さて、スペシャライゼーションのピン留めをブロックしたくありません。 ただし、 impl Drop for Pinned<MyStruct>許可すること、またはより一般的には、コンパイラが現在impl<params> Drop for MyStruct<params>許可するのと同じ条件下でimpl<params> Drop for Pinned<MyStruct<params>>を許可することは、特殊化のサブセットであることが保証されていると私は主張します。許可するので、今日特別なケースを作成した場合、最終的にはより一般的なルールになります。

しかし、繰り返しますが、これは分離可能です。 人々がこれを気に入らなければ、代わりに別の特性を持つことができます。

Unpin

しかし、 derefがないことが実際には小さな問題であることに同意するかどうかは、本当にわかりません。たとえば、現在の状態では、 &Pinned<Vec<T>>何もできません。 T: !Unpinであり、基本的にすべての既存のライブラリタイプに同じことが当てはまります。 これは、 Unpin動作方法に起因する問題であり、特定の種類の参照ではありません。

えーと…わかりました、私の発言を訂正させてください。 Pinned::derefが存在する必要がありますが、 Unpin制限されている必要があります。ただし、これをMoveと呼びます。

唯一の理由Deref IMPLのためにPinMutで問題が発生RefCellされている（とは異なり、 DerefMut IMPL）それは上で囲まれていないUnpin 。 そして、限界がない理由は、ユーザーが&MyImmovableTypeを取得できるようにし、不動の型が&selfをとるメソッドで特性を実装し、 &Tをとるジェネリック関数に渡せるようにしたいからです。 &mut selfでは基本的に不可能ですが、 mem::swapまたはmem::replace移動できないため、ほとんどの場合&selfで機能します。 mem::replace –つまり、 RefCellを使用する場合を除きます。 しかし、理由は、既存の参照との互換性は、不変の参照への制限が恣意的であると感じたとしても、それが恨みを引き起こしたとしても、サポートされるべきであるほど十分に価値があります。

Pinnedを使用すると、不変と可変の両方の参照をサポートできます。 MyStruct直接ではなく、 Pinned<MyStruct>特性を実装するだけです。 欠点は、 &Tを受け取るが、個別にSelf: Sizedバインドがある特性または関数と互換性がないことです。 しかし、それらは比較的まれであり、しばしば意図的ではありません。

興味深いことに、 Pinned自体は、実際にはUnpinが存在する必要はありません。 結局のところ、なぜ誰かが実際に&Pinned<Vec<T>>作成するのでしょうか。 PinMut 、さまざまな特性にPinMut<Self>が必要になるため、可動タイプのこれらの特性の実装でさえ、 PinMutを受け取る必要があります。 私が言ったように、 Pinnedを使用すると、特性は引き続き&selfまたは&mut selfを取り、 Pinned<MyStruct>それらを実装します。 Vec<T>に同じ特性を実装したい場合は、 Pinnedする必要はありません。

ただし、潜在的なソースの1つは、フィールドアクセサーマクロです。 あなたが持っている場合

struct SomePinnable {
    gen: FakeGenerator,
    also_a_vec: Vec<Foo>,
}

その場合、最も単純な設計では、常にPinnedを使用してアクセサーが生成されます。

impl Pinned<SomePinnable> {
    fn gen(&self) -> &Pinned<FakeGenerator> { … }
    fn gen_mut(&mut self) -> &mut Pinned<FakeGenerator> { … }
    fn also_a_vec(&self) -> &Pinned<Vec<Foo>> { … }
    fn also_a_vec_mut(&mut self) -> &mut Pinned<Vec<Foo>> { … }
}

…そして、あなたがそれを望まないのであれば、 Pinnedに対処するのはあなた次第です。 実際、 Unpin / Moveが実際に存在するはずなので、これは問題ないと思います。以下を参照してください。 ただし、それが存在しなかった場合は、 Pinnedではなく、フィールドごとにオプトインして直接参照を受け取る方法があります。 つまり、あなたは持っているでしょう

    fn also_a_vec(&self) -> &Vec<Foo> { … }
    fn also_a_vec_mut(&mut self) -> &mut Vec<Foo> { … }

Pinnedと非Pinned両方のアクセサーがあるのは不健全ですが、どちらかそれ自体で問題ないはずです。

...しかし、ええ、私たちは持っている必要がありますMoveだけではないため、形質、 Pinned 。 たとえば、それはsize_of_valの新しいバージョンの境界の一部になります（修正：そうではありませんが、安全でないコードは、結果に基づいて任意の型をmemcpyしようとする前にそれをチェックすることが期待されますsize_of_val ）; 将来、サイズ変更されていない右辺値を使用すると、 ptr::readとmem::swapとmem::replaceの境界（ Sizedから緩和）になります。 もし私たちが&move手に入れたら、それはあなたが1つから抜け出すことを可能にするための限界になるでしょう。 同様のことが、保証されたコピーの省略にも当てはまります。

したがって、特性がある限り、 T: MoveバインドされたPinned::deref （およびderef_mut ）を持たない理由はありません。

[編集：pythonesqueが私に思い出させたように、これはUnpinとは異なるセマンティクスを持っているので、気にしないでください。]

（そして、 VecやBoxようなタイプは、要素タイプがMoveであるかどうかに関係なく適用されるように、手動でMove実装する必要があります。）

えーと…わかりました、私の発言を訂正させてください。 Pinned :: derefは存在する必要がありますが、Unpinで制限されている必要があります-これをMoveと呼びます。

さて、待ってください。 これは?MoveまたはMoveですか？ 前者は、多くの場合、 !Unpin型を構築することさえできないことを意味します。 後者は、正確には、 Pinned<T>ようなタイプをどのように参照しているのか疑問に思います（ ?DynSizedは実際にはそれらに適切な境界ではないため）。 私は確かにそれらが同じではないことを願っています-そうでなければ、 MoveをUnpinとして扱うことは、私たちが避けようとしている正確なことをもう一度行い、タイプが構築された瞬間に動か​​ないようにします。

欠点は、＆Tを取得するが、個別にSelf：Sizedバウンドを持つ特性または関数と互換性がないことです。 しかし、それらは比較的まれであり、しばしば意図的ではありません。

はるかに重要な実用上の欠点があります。それは、これらの特性または機能のいくつかが実際に＆Pinnedで機能することです。今日。 それらはそれで動作するようにすることができますが、それは膨大な数の追加の特性実装を必要とし、（私が言ったように）おそらく既存の#[derive]実装の大幅なオーバーホールを必要とします。 これは、新しいものにも支払わなければならないコストでもあります。 !Unpinタイプで機能させるには、すべてを&Pinned<Self>実装する必要があります。 これは、 PinMutよりも&mut selfをとる特性の（はるかに）良い状況ですが、 &self場合はさらに悪い状況であり、（おそらく）はるかに一般的です。 したがって、これがより正しい解決策であると私が言う理由は（既存のRustライブラリがあまりない場合は、 Pinnedバージョンの方が良いという意味で）、おそらくより使いやすいものではないでしょう。

Pinnedを使用すると、私が言ったように、トレイトは＆selfまたは＆mut selfを取り続け、Pinnedのためにそれらを暗黙的に使用します

今回はPinnedだけを使用して、 VecのAPIサーフェスにすべてのトレイトを再実装することは、私にはそれほど素晴らしいことではありません（特に、一部のトレイトが機能しないため）。 ケースバイケースでDerefを選択的に実装するか（たとえば、 &Pinned<Vec<T>>を&[Pinned<T>]に移動させる）、または単にVec全体を実装するかのどちらかだと確信しています。 Unpinなります（そしてピンの投影を許可しません）、はるかに正気です。 いずれにせよ、どちらもまったく何もしないよりも多くの作業であり、動かせないものがそれらと連携するためには、既存のタイプと特性の全体に複製する必要があります。

そうでなければ確信することができます-私は実際にPinnedソリューションを考えれば考えるほど好きです-しかし、 Pinned<T>これらすべての新しい特性の実装が実際にどこにあるのかわかりませんから来る; 人々はそれらを実装することを気にしないだろうと私には思われます。

興味深いことに、Pinned自体は、Unpinが存在する必要はまったくありません。 結局のところ、なぜ誰かが実際に＆Pinnedを作成するのでしょうか>？

これを実行する理由はかなりあります（たとえば、固定されたタイプにVecれている）。 煩わしいコレクションは、この種のシナリオに頻繁に遭遇します。 人々が既存のコンテナへのPinned参照を決して望んでいない、またはUnpin機能させるためにオプトインする必要があるという考えに基づいた提案は、うまく機能しない可能性が高いと思います。 Unpinバウンドを追加してRustの通常のエコシステムに基本的にオプトインできないと、信じられないほど混乱します（実際、不動のタイプのほとんどすべてのユースケースは非常に難しくなります）。

PinMutを使用すると、さまざまな特性でPinMutが使用されます、したがって、可動タイプのこれらの特性の実装でさえ、PinMutを受け取る必要があります。

承知しました！ Pinnedバージョンの大きな利点は、変更可能な固定参照に明確な特性を必要としないことです。 ただし、他のほとんどすべてのシナリオでは、 PinMutよりも悪いか中立であり、 derefです。

ピン留めされたアクセサーとピン留めされていないアクセサーの両方があるのは不健全ですが、どちらかそれ自体で問題ないはずです。

安全でないコードを実装するために安全でないコードを必要とする手動アクセサーは、私には悪い考えのように聞こえます。 そのような提案がアクセサの生成を安全にする方法がわかりません（ピン留めされていないアクセサを提供しないようにunsafeを書かせずに、誰かがそれを提供しないようにするにはどうすればよいですか？）。 ただし、ご存知のように、 Move （実際にはUnpin意味すると仮定して）正常に機能します。

したがって、トレイトがある限り、T：MoveバウンドでPinned :: deref（およびderef_mut）を使用しない理由はありません。

承知しました。 ここでは特に!Unpinタイプについて話します。 Unpinタイプは、 PinMutでも構成上の問題がないため、私の観点からはそれほど関連性がありません。 ただし、ジェネリックのUnpin （またはMove ）の境界は快適ではなく、理想的には可能な限り回避できるはずです。 繰り返しますが、前に言ったように、 Unpinと!Sizedによって暗示されているものはすべて同じではなく、同じものとして扱うことはできないと思います。

…しかし、ええ、ピン留めではなく、移動特性が必要です。 たとえば、これは新しいバージョンのsize_of_valの境界の一部になります。 将来、サイズ変更されていない右辺値を使用すると、ptr :: readとmem :: swapとmem :: replaceのバインド（Sizedから緩和）になります。 ＆moveを取得した場合、それはあなたが1つから移動できるようにするための境界になります。 同様のことが、保証されたコピーの省略にも当てはまります。

これは、 !Unpin （タイプがデフォルト以外のピン留め不変条件を持つことができることを意味します）と!DynSizedような!Move再び混同していると思います。 望ましくないすくみ行動を引き起こさずに、それらを実際に同じにすることはできません。

おっと、あなたは完全に正しいです。 UnpinをMoveと同じにすることはできません。

だから私はUnpinを信じることに戻ったと思うので、 Pinned::derefはまったく存在しないはずです。代わりに、（アクセサ生成マクロのような）状況を回避する必要があります。 &Pinned<MovableType>ようなタイプを取得します。 しかし、それは別の特性として存在すべきであるという議論があるかもしれません。

今回はPinnedだけで、 VecのAPIサーフェスにすべてのトレイトを再実装することは、私にはそれほど素晴らしいことではありません（特に、一部のトレイトが機能しないため）。 ケースバイケースでDerefを選択的に実装するか（たとえば、 &Pinned<Vec<T>>を&[Pinned<T>]に移動させる）、または単にVec全体を実装するかのどちらかだと確信しています。 Unpin （そしてピンの投影を許可しない）のは、はるかに正気です。

ええ、私は間違いなくVecのAPIサーフェス全体またはそのようなものを再実装することを提案するつもりはありませんでした。

&Pinned<Vec<T>>は無関係な不​​変条件のように見えるため、 Vecで「ピンプロジェクション」を許可しないことをお勧めします。 Vecを移動することは許可されているはずです。内容のピンを無効にします。

別の方法として、 Vec<T>からVec<Pinned<T>> Vec<T>への変換を許可するのはどうですか。これはVec APIのほとんどを持ちますが、再割り当てを引き起こす可能性のあるメソッドを省略します。 つまり、 Vecの定義を現在のstruct Vec<T>からstruct Vec<T: ?Sized + ActuallySized>に変更します。これは、基本的にSizedがActuallySized + Moveエイリアスになる、あまり馬鹿げていない名前です。 Sizedと、変換を実行するメソッドを追加します。

また、組み込みスライスタイプの要素タイプの境界をSizedからActuallySizedに変更する必要があります。 これについて考えると、 SizedをSized以外の意味に変更することの厄介さを思い出しますが、一方で、 Sized大部分が制限されることは事実です。既存のコードでは、本質的にMove必要です。 スライスにインデックスを付けるためにsize_of::<T>()を知る必要があるのは、ちょっとした例外です…

承知しました！ Pinnedバージョンの大きな利点は、変更可能な固定参照に明確な特性を必要としないことです。 ただし、他のほとんどすべてのシナリオでは、 PinMutよりも悪いか中立であり、 derefです。

また、他のものとの競合を犠牲にして、 RefCellとの競合を回避できるという利点もあります（ Sized境界）。

安全でないコードを実装するために安全でないコードを必要とする手動アクセサーは、私には悪い考えのように聞こえます。 そのような提案がアクセサの生成を安全にする方法がわかりません（ピン留めされていないアクセサを提供することを、彼らがそうしないと主張するために安全でないと書くことなく、どのように阻止しますか？）。

アクセサーはMyStruct直接ではなく、 Pinned<MyStruct>に実装されているためです。 &mut MyStructがある場合は、いつでも手動でフィールドにアクセスして&mut MyFieldを取得できますが、それでも移動可能な状態です。 &mut Pinned<MyStruct>がある場合、 &mut MyStruct取得することはできません（ MyStructが!Unpinか、 Unpinが存在しないと仮定します）。したがって、フィールドに到達するにはアクセサを使用する必要があります。 アクセサーは&mut Pinned<MyStruct>受け取り（つまり、 &mut selfを取り、 Pinned<MyStruct>実装されます）、 &mut Pinned<MyField>または&mut MyFieldいずれかを提供します。選択したオプションによって異なります。 ただし、重要な不変条件は、 &mut Pinned<MyField>を取得して書き込み、借用を解放してから&mut MyFieldを取得できないようにする必要があるため、どちらかのタイプのアクセサーしか使用できません。

これを実行する理由はかなりあります（たとえば、固定されたタイプにVecれている）。 煩わしいコレクションは、この種のシナリオに頻繁に遭遇します。 人々が既存のコンテナへのPinned参照を決して望んでいない、またはUnpin機能させるためにオプトインする必要があるという考えに基づいた提案は、うまく機能しない可能性が高いと思います。 Unpinバウンドを追加してRustの通常のエコシステムに基本的にオプトインできないと、非常に混乱します（実際、不動のタイプのほとんどすべてのユースケースは非常に難しくなります）。

私はあなたがここで何を意味するのか完全には理解していませんが、それはあなたがUnpin対Move私自身の間違いに反応していたためかもしれません:)

これで修正されました... Unpinが存在する場合、 Vecはそれを暗示するはずです。 しかし、それが存在しないと仮定すると、あなたが参照しているシナリオは正確には何ですか？

フィールドの1つとしてVecを持つ構造体の場合、フィールドへの固定されていない参照を取得する方法を上で説明しました（固定された参照を取得できないという犠牲を払って、結構です）。

typeパラメーターに応じて、 Vec含む可能性のあるフィールド、または不動の型を含む可能性のあるフィールドを持つジェネリック構造体が必要な場合、これは問題になると思います。 ただし、実装するかどうかをすべてが考えなければならないUnpin特性を必要とせずに、これを解決する別の方法があるかもしれません。

@comex

別の方法として、Vecからの核変換を許可するのはどうですかヴェネトへ>、ほとんどのVec APIがありますが、再割り当てを引き起こす可能性のあるメソッドを省略していますか？

なぜなら...

つまり、Vecの定義を現在の構造体Vecから変更します。Vecを構築する、少し馬鹿げた名前の場合、基本的にSizedはActuallySized + Moveのエイリアスになります。 次に、再割り当てを引き起こす可能性のあるメソッドと、変換を行うメソッドにSizedバウンドを追加します。

...音は本当に、本当に複雑で、それは実際にあなたがしたいことをやっていないこと（これは通常の取得Vec<T>行うの&mut Pinned<Vec<T>>または何でも）。 それはあなたがに素敵なアナログ得るので、あなたは、事実の後にベクトルを固定することができますことを一種のクールなのであるBox<Pinned<T>> 、それは、直交心配です。 これは、所有されているタイプのプロパティであるピン留めがおそらく正しいという事実の単なる別の例です。 Unpinに関するすべては、参照型がどのように構築されるかという問題とはほとんど完全に無関係だと思います。

これで修正されました... Unpinが存在する場合、Vecはそれを実装する必要があります。 しかし、それが存在しないと仮定すると、あなたが参照しているシナリオは正確には何ですか？

私の主張を説明すると思うので、これに応答します。 Unpinがないと、 PinMutを介してi32フィールドを変更することさえできません。 あなたの構造で何かをしたい場合は、いくつかの時点では、多くの場合、（それは完全に不変でない限り）その中に何かを移動する必要があります。 Pinned<MyType>フィールドアクセサーを明示的に実装する必要があることは、特に問題のフィールドが常に安全に移動できる場合は、非常に煩わしいようです。 このアプローチは、組み込みのPinnedタイプで使用するのは本当に混乱するようです。これは、法的な予測がフィールドタイプに依存しない方法でフィールドごとに異なるため、Rustではすでに拒否されているためです。 mutフィールドが削除されたとき（そしてIMO、そのような注釈を追加する場合は、安全でないフィールドは実際には巨大なフットガンであるため、 unsafeの方が適しています）。 組み込みの固定型は、固定された列挙型を使いやすくするためのほぼ唯一の方法であるため、他の言語とある程度一貫性を持たせることができるかどうかに注意します。

しかし、もっと重要なのは...

タイプパラメータに応じて、Vecを含む可能性のあるフィールド、または不動のタイプを含む可能性のあるフィールドを持つジェネリック構造体が必要な場合、これは問題になると思います

これはUnpinのキラーユースケースであり、（私にとって）実際に機能しているように見えるという事実は非常に素晴らしく、ピン留めモデル全体を検証します（私たちが始めたとしても私が思うところまで） Rust 1.0より前は、おそらくUnpinそのままにしておきたいと思います）。 構造内にインラインで存在するジェネリックパラメーターも、現在の計画の場合にUnpinバインドする必要がある唯一の時間です（ほとんどすべての安全な参照のような型に無条件でUnpin実装させるため）通過します。

しかし、私が実際に得ていないのは、なぜUnpinを削除したいのかということです。 それを排除しても、本質的に何も購入しません。 PinMut超えてPinnedから得られるすべての素晴らしいもの（またはその逆）は、その存在とはほとんど関係がありません。 これを追加すると、Rustエコシステムの他の部分と簡単に互換性があります。 FWIW、 Unpin 、およびPinでのderefの無条件実装も、 Unpinすべてのタイプが同じように感じることを除いて、互いにほとんど関係がありません。 !Unpinタイプが行う苦痛（つまり、無条件のderef実装がより便利になる可能性があります）。 何かが足りないような気がします。

ドロップされる構造内の他のフィールドは、このコンテキストではローカル変数と見なされますか？ これは、ユーザー向けのドキュメントからははっきりしません。

十分に公平なことですが、これを追跡するためにhttps://github.com/rust-lang/rust/issues/50765を開きました。

@pythonesque

具体的には、RefCellの例は、Pinned :: derefが存在する場合、既存のタイプで動的にピン留めを強制することさえできないことを意味するため、かなり厄介です（特殊化で十分かどうかはわかりません）。 これはさらに、derefの実装を維持する場合、Pinを使用する場合とほぼ同じようにPinを使用してAPIサーフェスを複製する必要があることを示しています。 それを保持しない場合は、固定驚くほど使いにくくなります。

RefCellの解決策は、追加のメソッドborrow_pinとborrow_pin_mut （ Pin<RefCell<T>>を取る）を提供し、 RefCell内部の固定状態を追跡することです。実行時にPinMutとPinned両方で機能するはずです。 それで、ここであなたの議論はPinnedが役に立たないということですか？ RefCellでも、事態が悪化することはありません。

しかし、あなたは書く

違いは、derefをサポートしながら、PinMutを使用してソリューションをまとめることができることです。これは、Pinnedでは機能しないようです。

何を言っているのかわかりませんが、なぜこれがPinnedないのですか？

@comex

Pinned :: derefが存在するべきではないと思います。 安全なマクロ生成フィールドアクセサーで十分です。 それが「驚くほど使いにくい」のかわかりません。

derefとフィールドアクセサーの間の接続が表示されません。 しかし、 derefがPinned<T>でどのように問題になるかもわからないので、最初に上記の質問への回答を待つと思います。

@pythonesqueと同じように、参照の背後にある型（「所有型」）の固定状態を追跡する方が基本的に正しいと思います。 ただし、特に既存のRustエコシステムでの作業の制約を考えると、実際に人間工学に基づいた全体的なAPIに変換できるかどうかは疑問です。

「基本的に正しくない」と思われるアプローチを意図的に採用する場合は、安定させる前に、少なくとも実験のために多くの時間を残しておく必要があります。そうすれば、合理的に可能な限り自信を持って、そうすることができなくなります。それを後悔することになりそうです。

@pythonesque 、すごい、広範な要約をありがとう！ 作業中にRFCがあると聞いてうれしいです。 :)

その関数がmem::swapやmem::replaceようなものを使用しない限り、固定された値への可変参照をとる関数を呼び出すことは節約されます。 そのため、 PinからUnpin値へのすべての可変derefを安全でなくするよりも、これらの関数でUnpinバインドを使用する方が自然だと感じます。

関数が後でswapを使用するように更新された場合、固定された値への可変参照で関数を呼び出すことは安全ではなくなります。 swapとreplaceにこの境界がある場合、更新された関数も同様に行う必要があり、これが下位互換性のある変更ではないことがより明確になります。

だから私が持っていたいくつかの考え：

1. 基本的に、 DropはUnpinと同じ特権を提供します-以前はPinMutあったものに&mutを取得できます。 そして、 Dropは安全です。つまり、 Unpinは安全であるはずです（これはmem::forgetあり、リークポカリプスです）。
2. これは、ピン留め解除ジェネレーターを処理しない現在の先物ベースのAPIのようなものが、 self: PinMut<Self> （ unsafe impl Unpin ）を使用しても、すべて100％安全に実装できることを意味するためです。
3. Unpinが安全な場合、APIは適切ですか？ 答えはイエスです。ジェネレーターがUnpin実装しておらず、プロジェクトを!Unpinタイプに固定するのが安全でない限り、すべてが安全です。
4. しかし、これはピンの突起が安全でないことを意味します！ 理想的ではありません。
5. SelfがUnpinまたはDrop実装していない場合、ピンの投影は安全

Unpin完全に削除し、代わりに極性を反転することを含む、このライブラリAPIのより言語でサポートされる代替案について、いくつかのアイデアがあります-代わりに、これらの保証を取得することを選択Pin特性オプトアウトします。 しかし、これにはかなりの言語サポートが必要ですが、現在の実装は完全にライブラリベースです。 よく考えてからまた投稿します。

私は忘れ続けているので別の注意：

ピンプロジェクションの安全性は、フィールドタイプではなく、セルフタイプのみに依存します。これは、フィールドタイプが、無条件であるパブリックAPIの安全性を保証する必要があるためです。 したがって、再帰的なチェックではありません。 SelfがPinから何も移動しない場合は、どのタイプのフィールドにもピン投影しても安全です。

@withoutboats FWIWこれは、 @ cramertjと私が前回の議論で到達した結論と

@withoutboats

基本的に、DropはUnpinと同じ特権を提供します。つまり、以前はPinMutにあったものに＆mutを取得できます。 そして、Dropは安全です。つまり、Unpinは安全である必要があります（これはmem :: forgetとleakpocalypseです）。

リークポカリプスとの関係はわかりませんが、そうではないことに同意します。 私が少し躊躇している唯一の理由は、それがDropである限り、これは私にとってはコーナーケースのように感じられ、多くの人が気にする必要がないということです。 それが利点かどうかはわかりませんが。 そしてとにかく、安全なUnpinは、ここでの一貫性を高めるだけでなく、 Drop問題を特別なケースにすることなく「解決」します（代わりに、すべてのimpl Dropように考えることができます暗黙のimpl Unpin ）; あなたの言うことから、それは物事のFuture側でも使いやすくなります。 だから、それは全体的な勝利のようです。

@pythonesque何かが足りない場合を除いて、安全なUnpinは、侵入的なコレクションに対しても新しい問題を引き起こしませんか？ 安全なDropにもかかわらず機能した場合でも、機能するはずです。

@withoutboats

SelfがUnpinまたはDropを実装していない場合、ピンの投影は安全です[編集：trueまたはfalse？]そのチェックを自動化できますか？

最初にここでフィールドタイプについても言及しましたが、なぜそれが適切だと思うのかを尋ねようとしていました。 投稿を編集しているようです。 :)私はこれがSelfタイプについてのみであることに同意します。 以下では、私の言葉であなたの議論をほとんど繰り返します。

基本的に、問題は次のとおりです。 Selfはどのようにしてピン留め不変条件を選択しますか？ デフォルトでは、（安全でないコードが存在する場合でも）ピン留め不変条件は所有されている不変条件とまったく同じであると想定します。つまり、不変条件は場所に依存せず、このタイプはピン留めを行いません。 PinMut<T> &mut Tに変換する以外に何もできない限り、それは安全な仮定です。

フィールドプロジェクションを有効にするには、ピン留め不変条件を「すべてのフィールドがそれぞれのタイプの不変条件でピン留めされる」必要があります。 その不変量は、フィールドタイプに関係なく、ピン留めの予測を簡単に正当化します（つまり、必要なピン留め不変量を選択できます）。 もちろん、この不変条件はPinMut<T>を&mut Tに変換することと互換性がないため、そのような型がDropまたはUnpinないことを確認することをお勧めします。

リークポカリプスとの関係はわかりませんが、そうではないことに同意します。

単なるアナロジー-アンピンはmem :: forgetがRcサイクルにあるようにドロップすることです。 mem :: forgetは元々安全でないとマークされていましたが、それを正当化する理由はありませんでした。 （そして、Rcサイクルがエッジケースであるという同じ議論が、mem :: forget safeのマーキングに対して行われました。）

Discordから（精神的に）コピーして貼り付けると、問題を裏返しただけではないという証拠が本当に欲しいです：構造的なピンアクセサーを実装するのが安全でないようにすることで、Unpinを安全に実装できるようにします（これはどの場合にも当てはまります）導入された安全でない特性ですよね？それでも安全でないコードを書かなければなりません）。 ほとんどの場合、完全に安全であるため、これは私を悩ませます-基本的に、型の明示的なUnpin implがない限り、型のDrop implがない場合は常に安全であるのと同じように、 我々ははるかに強い何かを必要としている現在の計画では、 -多くの少ないタイプのためにtrueになります（ちょうど私たちは図書館で行うことができるすべてについてです）！ -タイプのための明示的な固定を解除IMPLがあるはずです。

残念ながら、コンパイラが特定のタイプの手動のUnpin implがあるかどうかを、「実装がある」とは対照的にチェックする方法やかどうかはわかりません。また、特殊化との相互作用が悪いかどうかもわかりません。 型の作成者が構造的なピン留めを取得するために安全でないコードを記述する必要がないように、そのチェックを実行する明確な方法がある場合、 impl Unpinが安全であると私ははるかに幸せになると思います...それは実現可能と思われることですか？

私は簡単な質問があります、私は今理解しようとしています。 ジェネリックでは、すべてのジェネリックパラメーターのAPIを除いて、unpinはsizeedのような暗黙のバインドになりますか？

それはvecのために正しい必要があります安全を維持します。

サイズのような暗黙のバインドを解除します

番号。

vecが安全であり続けるためには、それは正しくなければなりません。

どうしてそう思うの？

迷惑な事@MajorBreakfastは今日打っていること： PinMut::get_mutあなたに与え&mutの寿命を持つ元PinMut以来、しかし、同じことを行うには安全な方法はありません、 DerefMutは、 PinMutへの可変参照の存続期間で借用を提供します。 おそらく、 get_mut安全なものにして、 get_mut_uncheckedを追加する必要がありますか？

こんな意味？

fn get_mut(this: PinMut<'a, T>) -> &'a mut T where T : Unpin

ええ、私たちはそれを持っている必要があります。

@RalfJungその通り。

これを使用したい先物クレートのメソッドは次のようになります。

fn next(&mut self) -> Option<&'a mut F> {
    self.0.next().map(|f| unsafe { PinMut::get_mut(f) })
}

FにはUnpinバインドがあり、完全に安全ですが、安全でないブロックを使用する必要がありました。 現在、 PinMut存続期間を保持する参照を生成する安全な方法はありません。

ええ、それはAPIの単なる省略です。

PRを準備しますか、それとも私がすべきですか？

できます。 それをget_mutとget_mut_uncheckedと呼びたいですか？

安全なmapを追加し、現在のものの名前もmap_uncheckedします。 主に一貫性のため。 その後のすべての危険な機能PinMutで終わる_uncheckedおよび安全同等のを持っています

get_mutおよびget_mut_uncheckedと呼びますか？

合理的に聞こえます。

安全なmap追加します

そこに注意してください。 どのように見せたいですか？ マップが安全でない理由は、安全なマップを作成する方法がわからないためです。

そこに注意してください。 どのように見せたいですか？

あなたが正しい。 戻り値にUnpinバインドが必要です。

https://github.com/rust-lang/rust/pull/51730

私はちょうど考えを持っていました： PinArcどうですか？ 先物クレートのBiLock impl（https://github.com/rust-lang-nursery/futures-rs/pull/1044）でそのようなものを使用できます。

@MajorBreakfast PinArc （およびPinRcなど）はPin （非Mutバージョン）に依存します。 私はそれを追加するつもりですが、それが提供する保証について正確にコンセンサスがあるかどうかはわかりませんでした。

PinArc追加すると何かが追加されるかどうかはもうわかりません^^ ' Arcすでに「借用したコンテンツからの移動」を許可していません

あなたはうちの移動することができます@MajorBreakfast Arc使用してArc::try_unwrap 。 それを削除するか、 T: Unpin境界を導入することは、後方互換性のない変更になります。

こんにちは！
ピンアクセサーを安全に動作させる方法について少し考えてきました。 私の知る限り、ピンアクセサーの問題は、 T: !Unpin + Drop組み合わせがある場合にのみ発生します。 そのために、私は、このようなタイプの可能性を防止しようとしているいくつかの議論を見たT例えば形質を作る-既存の!UnpinとDropさまざまな方法で相互に排他的ではなく、そこに下位互換性を損なうことなくこれを行う明確な方法ではありませんでした。 この問題をさらに詳しく見ると、タイプが!UnpinとDropになるのを妨げることなく、安全なピンアクセサーを取得できます。そのようなタイプをPin<T>入れることができなかっただけです。 Unpin特性がどのように機能するかという精神に基づいていると私は信じています。

現在、タイプが!UnpinとDrop両方であるPin<T>安全に入るのを防ぐための「解決策」があります。 まだ錆びていない機能が必要なのが問題ですが、そのスタートを期待しています。 とにかくここにコードがあります...

/// This is an empty trait, it is used solely in the bounds of `Pin`
unsafe trait Pinnable {}

/// Add the extra trait bounds here, and add it to the various impls of Pin as well
struct Pin<T: Pinnable> {
    ...
}

/// Then we impl Pinnable for all the types we want to be able to put into pins
unsafe impl<T: Unpin> Pinnable for T {}
unsafe impl<T: !Unpin + !Drop> Pinnable for T {}

Unpinタイプと、 !Unpinだけでなく!Dropタイプも、ピンアクセサーに問題はありません（私の知る限り）。 これは、 Dropを使用する既存のコードを壊すことはなく、 Pin構造体に入れることができるものを制限するだけです。 誰かが両方可能にするタイプの必要性は低い*場合は!UnpinとDrop （と実際の内側に配置することができPin ）、彼らのことができるようになりますunsafe impl Pinnableタイプは

*私は経験がありませんPin 、私は、誰かのニーズにほとんどの場合ことを願っていますimpl Dropであるタイプのための!Unpinによって引き起こされていませんドロップする必要があるのは本質的に!Unpinですが、 Dropフィールドと!Unpinフィールドを持つ構造体が原因です。 この場合、 Dropフィールドは、 !Unpinフィールドを含まない独自の構造体に分割できます。 説明がおかしいと思うので、必要に応じて詳しく説明しますが、コメントの本文を意図したものではないので、とりあえず短くしておきます。

私の知る限り、ピンアクセサーの問題は、T：！Unpin + Dropの組み合わせがある場合にのみ発生します。

それは「and」というより「or」のようなものです。

ピンアクセサーは、ピン留めの「構造的」解釈を意味します。 Tがピン留めされると、そのすべてのフィールドもピン留めされます。 impl UnpinとDropは、タイプがピン留めをまったく気にしないと想定しているため安全です。 Tがピン留めされているかどうかは、違いはありません。 特に、 Tのフィールドはどちらの場合も固定されません。

ただし、これは、アクセサが安全に追加できるタイプが!Unpin + !Dropタイプであると言ったときにすぐにわかります。 （タイプは、安全でないコードで何も悪いことをしないように注意する必要がありますが、 Unpin ad Dropは、ピン留めアクセサーを壊す2つの安全な方法です。）

この問題をさらに詳しく見ると、タイプがピンを外してドロップするのを妨げることなく、安全なピンアクセサーを取得できます。そのようなタイプをピンに入れることができなかっただけです。。

私はフォローしません。 なぜそれで十分だと思いますか？ もしそうなら、タイプを固定できないのに、なぜ固定されたアクセサに興味があるのでしょうか...？

それは「and」というより「or」のようなものです。

とりあえずこれについて話しましょう。私のアイデア全体はこれとは逆に基づいていたので、これを誤解した場合、残りのアイデアは役に立ちません。

私の（現在の）理解では、 Pin<T>は事実上&mut Tため、 Unpinタイプのピンアクセサーはドロップに関係なく完全に健全です。 また、 dropが&mut self取得できる唯一の関数であるため、 !Dropタイプのピンアクセサーは、 !Unpinタイプの場合でも完全に健全です。 !Unpinタイプでは、 Pinに入ると、何も移動できなくなります。

それを間違えた場合はお知らせください。 ただし、そうでない場合は、 Unpin + Dropタイプまたは!Unpin + !Dropタイプは、ピンアクセサーで完全に問題なく、問題のタイプは!Unpin + Dropです。

@ashfordneil

また、！Dropタイプのピンアクセサーは、！Unpinタイプの場合でも、完全に健全です。ドロップは、ピンに入ると！Unpinタイプで＆mut selfを取得できる唯一の関数であるため、何もできません。物事を移動します。

struct Foo(InnerNotUnpin); impl Unpin for Foo {}と書くと、 PinMut<Foo>からPinMut<InnerNotUnpin>に移動するのは不健全です。 投影が適切であるためには、（a）ドロップ実装を禁止し、（b）フィールドがUnpin場合にのみ、構造がUnpinことを確認する必要があります。

（a） !Unpinであるものにドロップインプを禁止するだけでいいですか？
（b） Unpin実装は安全ではないという事実によって処理する必要があります-実際には固定できないのに型を固定解除できると安全に主張することで、自分の足を撃つことができることを確認してください-しかし、ラベルを付けることは可能な限り可能ですあるべきではないのにSyncようなもので、そのように不健全な振る舞いになってしまう

（a）ピン留めを解除することでドロップインプを禁止する必要がありますか？

ええ、しかしそれは後方互換性の理由から不可能です。

そして、それが私の要点になります-ドロップを禁止することは、下位互換性の理由から、！Unpinは不可能です。 ただし、！Unpinが発生するのを防ぐ必要はありません。 タイプの！Unpinマーカーは、そのタイプがPin内にあるまで意味がなく、約束もしません。したがって、！Unpinタイプのdrop implは、そのタイプがPin内にない限り、完全に健全です。 私が提案しているのは、ピンをPin<T>からPin<T: Pinnable>に変更することです。ここで、 Pinnable特性は、 Drop + !Unpin （またはそれ以上）の型を防ぐためのゲートキーパーとして機能します。一般に、ピンアクセサが問題となるタイプ）はPin内に配置されません。

その時点で、 Unpin特性を完全に役に立たなくしているのではありませんか？ また、現在のRustではまだ必要な範囲を表現できません。 「 UnpinとDropは互換性がない」と言えば問題ありません。 Pinnable似たものが必要なようです。 これがどのように役立つのかわかりません。

Unpinトレイトは、それ自体ではすでに「役に立たない」ものです。 特性_only_は、タイプが固定されると、ピンに入る前にタイプを移動できることを意味します。

@RalfJungと私は、これらのAPIについて話し合うための会議を開いたばかりで、APIを大幅に変更することなくAPIを安定させる準備ができていることに同意しました。

未解決の質問への解決

ピンAPIについての私の信念は次のとおりです。

1. PinMutとUnpinのコアAPIコンセプトは、組み込みの言語サポートを含まない可能な限り最高のソリューションを構成します。
2. これらのAPIは、必要であると判断した場合でも、将来の組み込み言語サポートを妨げるものではありません。

ただし、それらの制限とトレードオフに関して、私たちの決定を記録したいいくつかの未解決の質問があります。

Dropの問題

RFCをマージするまで発見されなかった問題の1つは、 Drop特性の問題でした。 Drop::dropメソッドには、自己&mut self受け取るAPIがあります。 これは本質的にSelf 「固定解除」であり、固定されたタイプが提供することになっている保証に違反します。

幸い、これは、ピンを使用して投影しようとしているコアの「不動ジェネレータ」タイプの健全性には影響しません。デストラクタを実装していないため、 !Unpin実装は実際にはそれを意味します。

ただし、これが意味するのは、自分で定義した型の場合、それらを「固定解除」することは必然的に安全であり、必要なのはDrop実装することだけです。 これが意味することにあるUnpinというunsafe trait実装：私たちに追加の安全買っていませんでしたDropの実装としては良いようですUnpin限り健全性があるとして、心配している。

このため、 Unpinトレイトを安全に実装できるようにしました。

ピンプロジェクション

現在のAPIの主な制限は、フィールドがUnpin実装していない場合、ピンプロジェクションを実行しても安全であると自動的に判断できないことです。 ピン投影は次のとおりです。

タイプTとフィールドaとタイプU与えられた場合、アクセスすることでPinMut<'a, T>からPinMut<'a, U>安全に「プロジェクト」できます。フィールドa 。

または、コードで：

struct Foo {
    bar: Bar,
}

impl Foo {
    fn bar(self: PinMut<'_, Foo>) -> PinMut<'_, Bar> {
        unsafe { PinMut::map_unchecked(self, |foo| &mut foo.bar) }
    }
}

現在のところ、フィールドタイプがUnpinを実装していない限り、 Unpin実装していない可能性がある場合、これは次のすべてが当てはまる場合にのみ安全です。

1. SelfタイプはUnpin実装しないか、フィールドタイプが実装する場合にのみ条件付きでUnpin実装します。
2. SelfタイプはDrop実装していません。そうでない場合、Selfタイプのデストラクタはそのフィールドから何も移動しません。

言語拡張機能を使用すると、これらの条件の一部が成立することをコンパイラーにチェックさせることができます（たとえば、 SelfはDropを実装せず、条件付きでのみUnpin実装します）。

安定した特性であるDropの問題のため、この問題はこの問題に関して私たちが下すことができるすべての決定にすでに存在し、言語の変更なしにピン投影を自動的に安全にする方法はありません。 いつかこれらの変更を加える可能性がありますが、その上でこれらのAPIの安定化をブロックすることはありません。

「ピン」保証の指定

RFCプロセスの後半で、 @ cramertjは、不動のジェネレーターに必要なものをわずかに拡張することで、侵入リストの保証を安全にカプセル化するためにピン留めを使用できることに気付きました。 ラルフはこの拡張機能の説明をここに書きました。

基本的に、ピン留めの保証は次のとおりです。

PinMut<T>があり、 TがUnpin実装していない場合、 Tは移動されず、メモリバッキングTは移動されません。デストラクタがT実行されるまで無効になります。

これは「リークの自由」とまったく同じではありません- Tは、たとえばRcサイクルの背後でスタックすることによってリークする可能性がありますが、リークされたとしても、メモリが無効になることはありません（プログラムまで）デストラクタは実行されないため）。

この保証により、スタックピン留め用の特定のAPIが除外されるため、最初は、これを含めるようにピン留めを拡張することについて確信が持てませんでした。 ただし、最終的には、いくつかの理由でこの保証を使用する必要があります。

1. このマクロのように、他のさらに人間工学的なスタック固定APIが発見され、欠点が排除されています。
2. 利点はかなり大きいです！ これらの種類の煩わしいリストは、Rustをガベージコレクションされた言語と統合する
3. Ralfは、これらのAPIのいくつかがそもそも本当に健全であるとは決して確信していませんでした（特に「永続的な借用」に基づくもの）。

APIの再編成

ただし、APIに最後に提案された変更を1つ加えたいと思います。それは、物事を移動することです。 存在するAPIを確認したところ、ラルフと私は、 Dropなどに関連する高レベルの保証と不変条件を説明するのに適した場所がないことに気付きました。 したがって、私は提案します

1. 新しいstd::pinモジュールを作成します。 モジュールドキュメントは、ピン留めの概要、それが提供する保証、およびその安全でない部分の不変のユーザーが支持することが期待されるものを提供します。
2. PinMutとPinBoxをstd::memとstd::boxedからpinモジュールに移動します。 Unpinをstd::markerモジュールに残し、他のマーカー特性も残します。

また、これらのタイプの安定化を完了する前に、より広範なドキュメントを実際に作成する必要があります。

Unpin実装の追加

Ralfと私は、 Unpin実装を標準ライブラリに追加することについても話し合いました。 Unpin実装する場合、常にトレードオフがあります。フィールドのタイプに関してUnpinが無条件に実装されている場合、プロジェクトをそのフィールドに固定することはできません。 そのため、これまでUnpin実装についてはあまり積極的ではありません

ただし、原則として次のように考えています。

1. ポインタを介したピンの投影は、決して安全なものとして扱われるべきではありません（下の注ボックスを参照）。
2. 内部の可変性によるピンの投影は、決して安全なものとして扱われるべきではありません。

一般に、これらのいずれかを実行するタイプは、ピンの投影を不可能にする何かを実行します（ Vecようにバッキングストアを再割り当てするなど）。 そのため、ポインターの後ろまたはUnsafeCell内にジェネリックパラメーターを保持するstdのすべての型に、 Unpin無条件実装を追加することが適切であると考えています。 これには、たとえばstd::collectionsすべてが含まれます。

あまり詳しく調べていませんが、これらのimplを追加するだけで、これらのタイプのほとんどで十分だと思います。

impl<T: ?Sized> Unpin for *const T { }
impl<T: ?Sized> Unpin for *mut T { }
impl<T: ?Sized> Unpin for UnsafeCell<T> { }

ただし、問題が1つあります。技術的には、 Boxを介したピン投影は、技術的に安全にできると考えています。つまり、 PinMut<Box<T>>からPinMut<T>への移行Boxが完全所有のポインターであり、それ自体を再割り当てしないためです。

T: Unpin場合、 UnpinがBox<T>に対してのみ条件付きで実装されるように、穴を設けることができます。 ただし、私の個人的な意見では、ピン留めは、所定の位置にピン留めされたメモリのブロックに関するものと考えることができるはずなので、ポインターの間接参照によるすべての射影は安全ではないはずです。

安定化をブロックせずにこの決定を遅らせ、時間の経過とともにこれらの実装を追加することができます。

結論

これまでピンAPIに多大な投資をしてきた他の人々の考えや、この安定化計画が妥当であるかどうかを聞いてみたいと思います。 残りの言語チームのために、次の投稿でfcpの提案を使って短い要約を作成します。

@rfcbotfcpマージ

少し再編成した後、既存のピンAPIを安定させることを提案しています。 あなたは私の以前の投稿でより長い要約を読むことができます。 私の意見のTL; DRは、現在のAPIは次のとおりです。

• 音
• 言語の変更なしで得られる限り良い
• それをより良くする言語変更との上位互換性

過去数か月にわたるピン留めの正確な保証と不変条件に関するすべての主要な質問を解決しました。現在の決定（安定させるべき決定だと思います）は、長い投稿に記載されています。

実際に物事を安定させる前に、いくつかの変更を提案しています。

1. PinMutとPinBoxを新しいstd::pinモジュールの下で再編成します。このモジュールには、不変条件と一般的なピン留めの保証に関する高レベルのドキュメントが含まれます。
2. stdの型にUnpin無条件の実装を追加します。これには、ポインターの間接参照の背後またはUnsafeCell内のいずれかにジェネリックパラメーターが含まれます。 これらの実装が適切である理由の正当性は、より長い要約にあります。

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

• [] @Kimundi
• [] @SimonSapin
• [] @alexcrichton
• [] @dtolnay
• [] @sfackler
• [x] @withoutboats

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

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

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

@rfcbotfcpキャンセル

コアとなる不変の決定を行う必要があるため、langにタグを付けているので、FCPをキャンセルして再起動します。

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

@rfcbot fcp merge前のマージメッセージと長い要約を参照してください、申し訳ありません！

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

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

懸念事項：

• api-refactor（https://github.com/rust-lang/rust/issues/49150#issuecomment-415230837）
• get_mut_unchecked_mut_mut（https://github.com/rust-lang/rust/issues/49150#issuecomment-417484798）
• 解決置き換えるhttps://github.com/rust-lang/rust/issues/49150#issuecomment -412672704

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

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

これが健全であるという自信を持ってうれしいです。 ただし、元のRFC以降に変更されたすべてを把握するのは困難です。 安定化のために提案されている設計を反映するようにRFCテキストを更新できますか？ （一般に、これは多くのRFCが抱える問題であり、実装期間中に大きく変化するため、RFCを読んで把握しようとしても無駄です。そこでより良い方法を見つける必要があります。）

RFCは仕様ではありません。 RFCを読むことは、実際のドキュメントの代わりにはなりません。

@bstrie RFCからの重要な変更（ Unpinは安全です）は、私の要約投稿でカバーされています。 長期的には、元のRFCを掘り下げるのではなく、 std::pin （安定化のブロッカー）のドキュメントを読んで、ピン留めAPIを理解する必要があります。

ドキュメントが安定化をブロックすることを目的としているが、ドキュメントがまだ作成されていない場合、このFCPは時期尚早ではありませんか？ 潜在的なコメント提供者が異なるソースをつなぎ合わせることによって暫定的なドキュメント自体を再構築することを期待することは、IMOが望むよりも参入障壁がかなり高いことです。

@bstrie文書化の前に、FCPを提案するのが標準的な手順です。 私はプレイの状態について非常に広範な要約コメントを書きました。これは、追跡の問題に従わなかった人には十分な情報を提供し、それほど多くのコンテキストを望まない人には短いコメントを提供するはずです。

もう少し詳しく説明すると、FCPは「これを安定させたいですか？」という質問です。 その答えが「いいえ」であることが判明した場合、ドキュメントに関する多くの作業が無駄になっています。 FCPの完了は、機能が即座に安定することを意味するものではありません。 それはそれを安定させるという決定がなされたことを意味します、そして今がそうするために必要な仕事をする時です。 これには、コンパイラとドキュメントの作業が含まれます。

2018年8月2日には、12:56で、ボートは[email protected]書きました：

@bstrie文書化の前に、FCPを提案するのが標準的な手順です。 私は、追跡の問題に従わなかった人に十分な情報を提供するはずの、プレイの状態に関する非常に広範な要約コメントを書きました

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

@withoutboats

ポインタを介したピンの投影は、決して安全なものとして扱われるべきではありません（下の注ボックスを参照）。
内部の可変性によるピンの投影は、決して安全なものとして扱われるべきではありません。

この点を少し明確にしていただけますか？ 標準ライブラリの型を具体的に参照していますか？ Boxと同様に、 Mutexようなタイプがあり、コンテンツを一意に所有しているため、ピン留めを投影できます（帯域外の場合もあります）。 少なくとも標準ライブラリの外では、 .lock()呼び出しでPinRef<InPlaceMux<T>>をPinMut<T>に投影する同時実行プリミティブを使用できるようにする必要があると思います。 「内部の可変性による投影」の場合のように。

@cramertj Mutex投影するのは危険なようです。 &Mutex 、次にMutex::lockへの安全な変換を使用して、 &mutを取得し、それを移動することができます。

編集：ああ、あなたは常に固定されたMutexを意味します。 たとえば、 PinMutex 。 はい、それはうまくいくでしょう。 &mut配布しない場合は、内部の可変性は問題ありませ

しかし、はい、完全に正確にするために、 @ withoutboatsのステートメントは、「タイプが常にピンである場合、つまり&mut決して配らない場合にのみ、内部の

@RalfJungその通りです。

しかし、現在、libstdにそのようなデータ構造がある可能性は低いようです。

そうです、ポインターや内部の可変性を介して投影しないことに関する規定の要件が、一般的なルールではなく、特にlibstdに関するものであることを確認したかったのです。

@cramertjは間違いなく

これを安定させるという決定には失望しています。 コンパイラのサポートがないと、潜在的な設計は少しハックに見えるので、短期的に何が起こるかについてはあまり心配していません。 ただし、長期的には、Rustがネイティブの不動タイプを取得した場合、 &selfおよび&mut self受け入れるトレイトメソッドで使用できない限り、真にファーストクラスであるとは感じられません。 結果として、ピン留めは、参照型ではなく、参照型のプロパティである必要があります。 もちろん、これは、ネイティブの不動タイプの将来の設計でも発生する可能性があります。 ただし、 Pin<T>が冗長になる結果になります。たとえば、一部のネイティブ&pin T非推奨のエイリアスだけでなく、まったく不要になります。 次に、 Pin<Self>を受け入れるFuture （および場合によっては他の多くの）などの特性を改良または非推奨にする必要があり、これには厄介な移行期間が必要になります。

厄介で、不可能ではありません。 しかし、過度に悲観的になるリスクを冒して、そのような移行を避けたいという願望が、ネイティブの不動のタイプの基礎として代わりに&pinを採用する方向に将来の決定を偏らせるのではないかと心配しています。それらは永久に二流です。 そして、短期的な設計の中で、 &Pinned<T>アプローチは実現可能であり、これらの上位互換性の懸念を回避し、他の利点もあると思います（たとえば、内部の可変性の問題を完全に回避します）。

しかたがない。 現状では、 Pinを使用するのを楽しみにしていますが、標準ライブラリに入るよりも、crates.ioにとどまるほうがよかったと思います。

これを安定させるには時期尚早であることに同意します。 現在、たとえばPinMut<Self>呼び出されるメソッド内の!Unpinタイプのフィールドにアクセスする場合など、状況によってはやや厄介です。 @withoutboatsの変更で状況が改善すると思いますが、

@Thomasdezeeuwどのような変更が状況を改善すると思いますか私が提案した変更は、その不便とは関係がないようです。

一般的なソリューションを作成する方法、つまりstdにメソッドを追加する方法はありませんが、futuresからのマクロのこのバリエーションは安全です。

macro_rules! get_mut {
    ($f:tt: $t:ty) => (
        fn $f<'a>(
            self: &'a mut std::mem::PinMut<Self>
        ) -> &'a mut $t
            where $t: Unpin
        {
            unsafe {
                 &mut std::mem::PinMut::get_mut_unchecked(self.reborrow()).$f
            }
        }
    )
}

struct Foo {
    bar: Bar,
}

impl Foo {
     get_mut!(bar: Bar);
}

@withoutboats Unpinデータへのアクセスしか提供しないので、安全ですよね？

@RalfJung正確に！ where句の行はそれを安全にします

@withoutboatsこれは素晴らしいマクロですが、 Unpinタイプでのみ機能します。

しかし、かかるだろう方法/マクロを追加することはできないPinMut<Self>とリターンPinMut<Self.field> 、好ましくで安全なコードを。 私が間違っている可能性が、私の考えでは、発信者guarenteesがあることならばということであるSelf固定され、そのようにあるSelf.field 、右？ これは、 Unpin実装していない型でも機能するはずです。

@Thomasdezeeuwこの問題は、「ピンプロジェクション」セクションの要約で説明されています。 Selfがチェックを生成できない他の特定のことを行わないことも保証しない限り、 !Unpinフィールドに投影することは安全ではありません。 Unpinを実装するフィールドに投影する機能のみを自動的に保証できます（これは常に安全であり、 where句で確認できるため）。

@withoutboats要約を読みましたが、誤解したかもしれません。 ただし、タイプTが!Unpin場合、 PinMut<T>はDerefMut for T実装しないため、安全でないコードがないと値を移動できません。 Dropトレイトにはまだ問題がありますが、それはタイプのフィールドにアクセスするよりも大きいです。 したがって、 T.fieldが!Unpinであっても、 PinMut<T>からPinMut<T.field>へのマッピングが安全でない理由はわかりません。

@Thomasdezeeuw先物PinMut内に型がありますが、そのフィールドの1つが固定されているとは見なされない状況があります。

@withoutboatsによるマクロの欠点は、 selfへの可変参照を保持しているため、一度に1つのフィールドにしかアクセスできないことです。 構造体フィールドアクセスには、この制限はありません。

固定APIを安定させることを決定することは正しい決定であると私は信じています。 ただし、最初に提案されたcore::pinモジュールを実装することをお勧めします。

ドロップ特性にはまだ問題がありますが、それはタイプのフィールドにアクセスするよりも大きいです。

いいえ、そうではありません。 Dropは、フィールドマッピングを行わない限り、実際には問題

ドロップ特性にはまだ問題がありますが、それはタイプのフィールドにアクセスするよりも大きいです。 だから私はPinMutからのマッピングを作るものがわかりませんPinMutへT.fieldが！Unpinであっても、安全ではありません。

明確にするために、 T: !Unpin証明を自動的に生成することもできません。 ただし、そうでない場合でも、 Drop implを使用する方法の例を次に示します。

struct Foo {
    field: UnpinFuture,
}

impl Foo {
     fn field(self: PinMut<Self>) -> PinMut<UnpinFuture> { ... }

     fn poll_field(self: PinMut<Self>, ctx: &mut Context) {
         self.field().poll(ctx);
     }
}

impl Drop {
    fn drop(&mut self) {
        // ...
        let moved_field = mem::replace(&mut self.field, UnpinFuture::new());

        // polling after move! violated the guarantee!
        PinBox::new(moved_field).as_pin().poll();
    }
}

@RalfJungが言うように、これはまさにDropの問題です- !Unpinフィールドへのピン投影を行わない場合、 Drop行うことはすべて問題ありません。

@withoutboatsによるマクロの欠点は、selfへの変更可能な参照を保持しているため、一度に1つのフィールドにしかアクセスできないことです。 構造体フィールドアクセスには、この制限はありません。

複数のフィールドにアクセスできるメソッドを作成できますが、関心のある組み合わせごとに作成する必要があります。

好奇心から、先物以外の具体的なユースケース、または少なくともこれらを今安定させたいという欲求を動機付ける何かがありますか（後でより多くの経験を積むのではなく）？

@comexが提起した点については、ここではこれ以上の議論はないようです。 pin参照ではなく型のプロパティにするという考えを思い出せないので、彼らは私をかなり興味深くさせました。 これはすでに他の場所で議論されていますか？ 「外側」からすべてを追うのは簡単ではありません、私は最善を尽くします;-)

次に、Pinを受け入れるFuture（および潜在的に他の多くの）などの特性改修または非推奨にする必要があり、これには厄介な移行期間が必要になります。

うーん。 一部のエディション関連の魔法で、これらのPinをサイレントにラップおよびアンラップし、変更を完全に下位互換にすることができますか？ 一種の大雑把ですが、過度ではありません。そのような移行の間、言語とAPIをクリーンに保ちます。

この質問に答えるには、アイデアをさらに具体化する必要があるかもしれません（これは以前スレッドで取り上げられたことを覚えていますが、どこにあるのかわかりませんでした）。

@yasammezこの辺りで価値志向のピン留めの議論を拾うことができました

確認のために、安定化への道には安全なフィールド予測の計画が含まれていませんか？ これにより、すべての先物ライブラリに多くの安全でないコードが導入されるように思われます。 私の経験では、手動のFuture implは珍しいことではなく、私のすべてがフィールドのポーリングを必要とすることを知っています。

この安全でないコードの多くが簡単に安全であることが証明されることは重要ではないと思います。 安全でないコードが存在するだけで、より現実的な安全でないコードを監査する能力が低下します。

短期的には

1. 先物ライブラリが開発したunsafe_pinnedマクロのようなマクロを使用して、内部ポーリングごとに1つの安全でないものに制限します。これは、私の長い要約で説明されている制約に対して検証する必要があります（マクロを使用することもできません。アクセサを手で書くだけで、 unsafeつだけです）。
2. フィールドにUnpinを実装するように要求し、そのような予測を簡単に安全にし、安全でないコードを必要とせず、ヒープに!Unpin先物を割り当てます。

@yasammezこのスレッドでhttps ： //internals.rust-lang.org/t/can-pin-own-its-referent-instead-of-borrowing-mutably/7238/20

@withoutboats私はオプションを理解していますが、Unpinを要求すると、チャネルを使用する非同期fnなど、自己借用するものと同様に、多数の先物との互換性が制限されます。 そして、安全でない汚染は本当の懸念です。

実際には、ライブラリをFutures 0.3に移行しようとしましたが、これらの理由で苦労していることがわかりました。

@tikueこれは、自動化された方法でチェックを提供することと上位互換性があります。 私たちはまだそれを完全に設計または実装していませんが、ここではそれが起こることを妨げるものは何もありません。

しかし、私はこの懸念を本当に理解していません：

そして、安全でない汚染は本当の懸念です。

「安全でない問題」は、私が感じるこのレベルに残されることが多すぎます。 unsafe全面的に禁止するだけです。

ほとんどのネストされた先物では、 unsafe_pinned!マクロを安全に使用できるかどうかを非常に簡単に判断できます。 チェックリストは通常​​次のようになります。

1. 私は将来のためにUnpinを手動で実装しませんでしたが、代わりに自動特性implに依存しています。
2. カスタムデストラクタがないため、将来のためにDropを手動で実装しませんでした。
3. 私が投影したいフィールドはプライベートです。

その場合：あなたは元気です！ unsafe_pinnedは安全に使用できます。

手動で実装しなかった場合はUnpinまたはDrop 、あなたが実際にそれについて考えるために持っていますが、その場合でもその必要はない、このような困難な問題：

1. 私が実装しなかった場合はUnpin 、それがあることを超えるI抽象的な未来に拘束されているUnpin 。
2. Drop実装した場合、デストラクタ中に将来のフィールドを移動することはありません。

参考までに@tikue 、属性ベースのソリューションの基本的な提案の要点を書きました。 これにはコンパイラのサポートが必要ですが、言語の重要な拡張は必要ありません。1つの新しい特性と1つの新しい組み込み属性だけです。

適切な&pin参照型を追加する、より「煩わしい」ソリューションもあります。これは、制約に関しては同じ形状ですが、言語全体により大きな影響を与えます。

PinMut::replaceどうですか？

impl<'a, T> PinMut<'a, T> {
  pub fn replace(&mut self, x: T) { unsafe {
    ptr::drop_in_place(self.inner as *mut T);
    ptr::write(self.inner as *mut T, x);
  } }
}

このようなメソッドを追加したくない場合でも、これが安全かどうかという質問に対する答えが必要です。 PinMut場合も、 PinBoxも、同様の方法が考えられます。

PinBoxは確かに安全だと思います。デストラクタを「インプレース」と呼ぶように注意しているので、これはメモリを再利用しているだけだからです。 ただし、値が早期に、つまり有効期間が終了する前にドロップされることについて、 PinMutについて少し心配しています。 これが常に大丈夫かどうかは私にはわかりませんが、反例を思いつくこともできません。 @cramertj @withoutboats何か考えはありますか？

（できればこれを

@rfcbot懸念置換

@RalfJung私はここで間違っている可能性がありますが、 Tがドロップでパニックになった場合、そのコードはダブルドロップできませんでしたか？

@RalfJungすでにPinMut::setます。

@ cramertjD'oh 。 ええ、私はこれをチェックするのにもう少し徹底的だったかもしれません。

騒音でごめんなさい、私の懸念は解決しました。

@rfcbot resolve replace

これは、 tokio_timer::Deadlineとの先物0.1 => 0.3の互換性のために今書いている実際のコードです。 PinMut<Future01CompatExt<Delay>>を作成する必要があります。ここで、 DelayはDeadlineフィールドです。

        let mut compat;
        let mut delay = unsafe {
            let me = PinMut::get_mut_unchecked(self);
            compat = Future01CompatExt::compat(&mut me.delay);
            PinMut::new_unchecked(&mut compat)
        };

unsafeの重要な使用に加えて、コンパイルされたバージョンを見つけるために、このコードで約5回の反復が必要でした。 ここで何が起こっているのかを書いたり考えたりするのはかなり非人間的です。

安全でないことを全面的に禁止することとこのコードの間には多くの余地があると思います。 たとえば、 map_uncheckedは、参照を返す必要があるため、このコードを支援するには制限が厳しすぎますが、このコードではFuture01CompatExt<&mut Delay>返す必要があります。

編集：非人間性のもう1つの原因は、マッチガードで変更可能に借りることができないため、PinMutこのようなコードでは動作しません：

`` `錆
self.poll_listener（cx）と一致しますか？ {{
// self.open_connections> 0の場合は以前
ポーリング:: Ready（なし）if self.open_connections（）> 0 => {
^^^^パターンガードで可変的に借用
Poll :: Pendingを返します。
}
Poll :: Ready（None）=> {
Poll :: Ready（None）;を返します。
}
}
「」

map_uncheckedについてのあなたのコメントは的を射ています。おそらく、ポインタの周りに一時的なものを返すこともできる、より一般的な署名があるかもしれません。

PinMut<Type>フィールドから&mut参照を取得するのが安全な場合のガイドラインはありますか？ Typeがフィールドが固定されていると想定しない限り、大丈夫だと思いますか？ プライベートである必要がありますか？

はい、フィールドはUnpin実装するか、フィールドのPinMutを作成しません。

@rfcbotの差異

私はかなりの量のPinMutベースのコードを書いていますが、多くのことが起こっているのは、ピン留めに依存しない操作が必要なことですが、 PInMut 「この記憶から抜け出さないことを約束します」という言い方としては、 &mutはありません。 ただし、これにより、すべてのユーザーに固定値が強制されます。これは不要です。 考えていたので、良いAPIを思い付くことができませんでしたが、「引数を固定する必要がある」と「固定された状態で作業できる」を区別する方法があれば素晴らしいと思います。引数"。

「分散」はそこでは間違った用語だと思います。 必要なのは、さまざまな参照型を抽象化するための関連型コンストラクターです：D

@RalfJungはい、そうです。 ただし、PinMutまたは＆mutから取得できるようなタイプを選択しますが、PinMutのようにしか使用できません。これは、特に適切にスケーリングされないことを知っています。 これは、一般的な任意のself_typesよりも達成可能だと思います：smile：「このような関数シグネチャに対して将来性があるとかなり確信している」で閉じるのがおそらく最善です：

impl MyType {
    fn foo(self: impl MutableRef<Self>, ...) { ... }
}

@rfcbotはapi-

ちょっとしたインスピレーションの構造体と昨夜、このAPIをリファクタリングして、すべてのポインターの固定バージョンを作成するのではなく、ポインターをラップするPinタイプが1つだけになるようにする方法を見つけました。 これは、APIの基本的な再形成ではありませんが、「メモリのピン留め」コンポーネントを構成可能な部分に引き出す方がよいと感じています。

• 新しいAPIについて説明しているブログ投稿は次のとおりです
• コードを表示するための要点は次のとおりです

nt-rsのネットワークスタックで作業していたとき、ピン留めされた参照は、ここに示すように、現在fold解決している「所有権のダンス」に役立つと言われました（tx.sendはtxをSend<<type of tx>>将来、着信データをループしてパケットを送信することが困難になります。） ピン留めはそのようなことでどのように役立ちますか？

@Redrield send()は、先物0.3で&mut自己を取ります。

@withoutboats先物でこの新しいAPIを試してみたいと思っています

新しいAPIは異なる識別子を使用するため、両方のAPIを同時に使用できるようにする必要があると思います。 両方のAPIが利用できる短い移行期間を設けることをお勧めします。これにより、実験、PRの準備、libcoreのfuturesAPIの新しいスタイルへの移植が可能になります。

@MajorBreakfastは、 type PinMut<T> = Pin<&mut T>;エイリアスを作成し、同じ方法をいくつか提供できる可能性があるようです。これにより、破損の規模と即時性が大幅に削減されます。

@withoutboats

したがって、新しいAPIでは次のようになります。

1. Pin<&T>とPin<&mut T>には「標準の固定」不変条件があり、その背後にある値は次のとおりです。
   1.a. Unpinでない限り、有効な&T / &mut Tなくなりました
   1.b. 別のメモリアドレスからのPinとしては使用されません。
   1.c. メモリが無効になる前に削除されます。
2. Pin<Smaht<T>>は「特別な」保証はありませんが、要求されたときに有効なPin<&mut T>とPin<&T>が返される点が異なります（APIが安全であるため、これは単なる標準の安全保証です。 ）。
   2.a. 我々はしたいですDerefPure保証、 Pin<Smaht<T>> 、それが変異されていない限り、同じ値を返すために必要とされるの？ 誰かがそれを望んでいますか？

不変量に関する修正。

Pin<Smaht<T>>の不変条件は次のとおりです。

1. Deref::deref(&self.inner)を呼び出すと、有効なPin<&T::Target> Deref::deref(&self.inner)が得られます（ &self.innerは安全な&Smaht<T>必要はないことに注意してください）。
2. Smaht<T>: DerefMut場合、 DerefMut::deref_mut(&mut self.inner)を呼び出すと、有効なPin<&mut T::Target> DerefMut::deref_mut(&mut self.inner)が得られます（ &mut self.innerは安全な&mut Smaht<T>必要はないことに注意してください）。
3. 破壊するためにself.innerのデストラクタを呼び出すことは、破壊しても安全である限り問題ありません。
4. self.innerは安全である必要はありませんSmaht<T> -他の機能をサポートする必要はありません。

@withoutboatsの提案についてredditの投稿にいくつかのフィードバックが投稿されました：

• （複数） Ownは奇妙な名前です。これを解決するための可能な方法については、以下を参照してください。

• ryaniは、 Deref<Target = T>を制約する実装に、その余分な汎用Tがある理由を尋ねます。 P::Targetだけを使用することはできませんか？

• jnicklasは、 Own特性の目的は何かを尋ねますが、慣例によりpinned固有のメソッドを追加するのはどうですか？ これは、APIユーザーがトレイトをインポートする必要がないことを意味しますが、ピン留め可能なコンストラクターに対してジェネリックになる機能は失われます。 これは大したことですか？ 特性の動機は十分に動機付けられていないようです：_ [彼らは]結局同じ形をしています。'_

• RustMeUp （私自身）は、 Own特性で、 ownメソッドの目的は何ですか？ オプトインしたいタイプがpinnedを実装したままにできないのはなぜですか？ これにより、トレイトの安全性が高まり、トレイトにPinnedという名前を付けることができます。これは、 Ownよりも扱いにくいと感じます。 独自の方法の理由は、十分に動機付けられていないようです。

別の質問を追加します：

なぜもないPin<P>自体もPin<P>::new_uncheckedに限定P: Deref ？

#[derive(Copy, Clone)]
pub struct Pin<P> {
    pointer: P,
}

impl<P: Deref> Pin<P> { // only change
    pub unsafe fn new_unchecked(pointer: P) -> Pin<P> {
        Pin { pointer }
    }
}

または

#[derive(Copy, Clone)]
pub struct Pin<P: Deref> { // changed
    pointer: P,
}

impl<P: Deref> Pin<P> { // changed
    pub unsafe fn new_unchecked(pointer: P) -> Pin<P> {
        Pin { pointer }
    }
}

どちらもPin<P>防ぎます。ここで、 P: !Derefインスタンスは、追加のメソッドが追加されない限り、使用できるものがないため、役に立たないものです。 おもう...

これが私の要点とryaniのフィードバックに対応したものです。

ryaniは、Derefを制約する実装がなぜその余分なジェネリックTがありますか？ P :: Targetだけを使用することはできませんか？

これらの2つの実装には、記述方法以外にまったく違いはありません。

なぜどちらのピンでもない

それ自体もピンも

:: new_uncheckedはPに制限されています：Deref？

私は意見がありません。 歴史的に、stdライブラリは構造体に拘束されていませんが、そのポリシーが動機付けられているのか、歴史的な事故なのかはわかりません。

＃53227が着陸した後にこれを実装することを計画していますが、物議を醸しているため、 Own特性は実装しません。 今のところ、 pinned Box 、 Rc 、 Arc pinned固有のコンストラクターだけです。

@ arielb1が書いたことをいくらかフォローアップして、ここでPin 、実際には「ポインター型コンストラクター」（ Boxや&'a mutような「種類」の* -> *に作用していると見なします。 私のブログ投稿のようにタイプごとの不変条件：Owned、Shared、Pinned-Owned、Pinned-Shared。

私はアイデアがあることであるため、適切な形式化は、このビューを必要だと思うPin<Ptr><T>とりTの不変量、（どこでも固定不変量を使用して）変換して、その後、適用Ptrその結果の型へのOwned定義方法を変更する必要がありますが、それはとにかく長期的に計画したものです。）形式主義の観点からは、 Ptr<Pin<T>>と書く方が本当に好きですが、試してみました。それとそれはRustではうまく機能しません。

したがって、 Pinに「オプトイン」するときにポインター型コンストラクターが行う約束は、 Deref / DerefMutを適用しても安全であるということです。つまり、入力が実際にPtrがそのタイプのPinned-Owned / Sharedバリアントに適用されると、出力はそのタイプのPinnd-Owned / Sharedバリアントを満たします。

ここでの「安全でない方法」は、実際には2つだけです（不変条件に注意する必要があるという意味で）。

impl<P, T> Pin<P> where
    P: Deref<Target = T>,
{
    pub fn as_ref(this: &Pin<P>) -> Pin<&T> {
        Pin { pointer: &*this.pointer }
    }
}

impl<P, T> Pin<P> where
    P: DerefMut<Target = T>,
{
    pub fn as_mut(this: &mut Pin<P>) -> Pin<&mut T> {
        Pin { pointer: &mut *this.pointer }
}

Pin<&T> -> &Tが安全な変換であり、 Unpinタイプの場合、同じことがPin<&mut T> -> &mut Tも当てはまるということを利用して、安全に使用できる他のすべてを安全なコードで実装できます。 。

我々は変更することができれば、私は好むDerefとDerefMutの実装Pinのようなものに

impl<'a, T: Unpin> Pin<&'a mut T> {
    pub fn unpin_mut(this: Pin<&'a mut T>) -> &'a mut T {
        this.pointer
    }
}

impl<'a, T> Pin<&'a T> {
    // You cannot move out of a shared reference, so "unpinning" this
    // is always safe.
    pub fn unpin_shr(this: Pin<&'a T>) -> &'a T {
        this.pointer
    }
}

// The rest is now safe code that could be written by users as well
impl<P, T> Deref for Pin<P> where
    P: Deref<Target = T>,
{
    type Target = T;
    fn deref(&self) -> &T {
        Pin::unpin_shr(Pin::as_ref(self))
    }
}

impl<P, T> DerefMut for Pin<P> where
    P: DerefMut<Target = T>,
    T: Unpin,
{
    fn deref_mut(&mut self) -> &mut T {
        Pin::unpin_mut(Pin::as_mut(self))
    }
}

それは、これら2つが新しいことを何もしないという点を思い起こさせるでしょう、彼らはPin<&[mut] T>から&[mut] Tへの安全な変換でas_ref / as_mutを構成するだけです- -これは明らかにas_ref / as_mutを他のポインター型コンストラクターが心配しなければならない唯一のものとして残します。

現在のPinMutにはborrowメソッドがあり、再借用を簡単にするために&mut selfを使用します（これにはselfが必要なので、自動借用が行われます）。 この方法は、 Pin::as_mutとまったく同じです。 ここでもこんなものが欲しいと思いますか？

スライスにget_unchecked_mutがあることに気づきましたが、ピンにはget_mut_uncheckedます。 一貫性のあるものに固執する必要があるようですか？

誰かがこれをrfcbotの懸念に追加できますか？

@rfcbot懸念get_mut_unchecked_mut_mut

rustcが何かをコピーするという1つの状況を忘れていることに気づきました---今のところ、それはおそらく大したことではありません。 私はパックされた構造体について話している。 パックされた構造体にドロップが必要なフィールドがある場合、rustcはそのフィールドのデータを整列された場所にコピーするコードを出力し、その上でdropを呼び出します。 これは、 &mut渡されたdropが実際に整列されていることを確認するためです。

私たちにとって、それはrepr(packed)構造体が「構造的」または「再帰的」なものであってはならないことを意味します。 固定-構造体自体が固定されている場合でも、そのフィールドは固定されているとは見なされません。 特に、このような構造体でpin-accessor-macroを使用することは安全ではありません。 それはそのドキュメントに追加する必要があります。

それは、すべてのピン留めドキュメントに塗りつぶされるべき巨大なフットガンのようです。

@alercah UnpinまたはDrop実装する既存の機能よりもはるかにフットガンではないと思います-確かに、どちらも#[repr(packed)]よりも固定値と一緒にはるかに一般的に見られます

それは公正です。 私の懸念は、誰かが自分が書いたのではないタイプに対してプロジェクションが安全であると考え、 packedが明らかに非自明であるため、そうすることが安全でないことに気付いていないかもしれないということです。 確かに、投影を行う人は誰でもこれを認識する責任がありますが、そのような投影が発生する可能性のある場所であればどこでも、追加で文書化する必要があると思います。

うーん、これは、ピン留めが再帰的ではないため、フィールドタイプに関係なく、パックされたすべての構造体がUnpinなる可能性があることも意味しますか？

@alercahパック型の実装方法についてはあまり詳しくありませんが、パック型をピン留めするのではなく、パック型にピン留めしても安全だと思います。 したがって、パックされたタイプを制御しない唯一のケースは、他の誰かのタイプのパブリックフィールドに投影する場合です。これは、 Dropなどの理由で同様に安全ではない可能性があります。 一般に、他の人のフィールドにプロジェクトをピン留めすることは、安全であることを示すピン投影を提供しない限り、賢明ではないようです。

うーん、これは、固定が再帰的ではないため、フィールドタイプに関係なく、パックされたすべての構造体が固定解除される可能性があることも意味しますか？

私が想像できるユースケースは、構造体全体のアドレスだけを気にする邪魔なリンクリストですが、そのデータのアドレスを気にせずにまとめたい、整列不良のデータがたくさんあります。

Futuresでの作業のため、Pin APIを学ぶ必要がありましたが、質問があります。

• Box無条件にUnpin実装します。

• Box無条件にDerefMut実装します。

• Pin::get_mutメソッドは常に&mut Box<T> （ Box無条件にUnpin実装するため）。

まとめると、完全に安全なコードで固定された値を移動できます。

これは意図されたものですか？ これが安全である理由は何ですか？

Box内のものではなく、 Boxを固定するPin<&mut Box<...>>があるようです。 Boxはスタック上のその場所への参照を決して保存しないため、 Boxを移動することは常に安全です。

おそらく欲しいのはPin<Box<...>>です。 遊び場リンク。

編集：もはや正確ではありません

@Pauan Boxが固定されているからといって、それが固定されていることを意味するわけではありません。 これに依存するコードはすべて正しくありません。

あなたが探しているのはおそらくPinBox 。これはあなたが言及した振る舞いを禁止し、 PinMut<Foo>を取得することを可能にします。

@tikue Pin<Box<...>>から移動することはまだ可能ですが、これは彼らが避けようとしていたことだと思います。

@tmandry間違っている場合は訂正してください。ただし、 Pin<Box<...>>は、ボックス自体ではなく、 Box内にあるものを固定します。 @Pauanの元の例では、 Pin<&mut Box<...>>があり、 Boxのみを固定していました。 Pin<Box<...>>がボックス内のものへの変更可能な参照を取得するのをどのように防ぐかを示す私の遊び場のリンクを参照してください。

PinBoxは最近削除され、 Pin<Box<T>>セマンティクスはPinBoxと同じになっていることに注意してください。

@tmandry PinBox<T>は削除され、NightlyでPin<Box<T>>に置き換えられました（指定したドキュメントリンクはStable用です）。 これが正しいナイトリーリンクです。

ああ、私が最後にこれらを使用してからルールが変更されたに違いありません。 混乱させて申し訳ありません。

@tmandryはい、変更はごく最近のものです。 物事はまだ流動的であるため、すべての変化に追いつくのは難しいです。

@tikueのコメントは正しいです。 ピンは1レベルの間接参照のみをピン留めすることを覚えておく必要があります。

@tikue @tmandry @withoutboats回答ありがとうございます！ とても助かりました。

では、2つの懸念の現在の状態は何ですか？ （ api-refactor ＆ get_mut_unchecked_mut_mut ）async / awaitシリーズ機能を熱心に待っている人として、 Pin APIはどのrustcバージョンをターゲットにするのだろうか？ 見積もりはありますか？

@ crlf0710安定化の提案を参照してください。

@withoutboats完了したようですか？ 閉じましょうか。

これを投稿する場所ではない場合はお詫びしますが、 Drop + !Unpin問題について考えていて、次のアイデアが出てきました。

1. 理想的には、 Drop::dropがfn(self: Pin<&mut Self>)であれば、問題はありません。 そのようなDrop PinDropと呼びましょう。 下位互換性の問題があるため、 DropをPinDrop置き換えることはできません。

1. Drop::drop(&mut self)の唯一の問題はDrop + !Unpin場合であるため、 Drop + Unpinに対してPinDropデフォルトの実装を導出できます（それ以降はPin<&mut T> : DerefMut<Target = T> ）そしてPinDropをrustcによって自動的に使用される特性にします（ドロップはスタックピン留めの唯一のケースであるため、 Pin::new_unchecked(&mut self)に感謝します）。

これがアイデアの大ざっぱなPoCです： https ： ＆ mode = debug ＆gist = 9aae40afe732babeafef9dab3d7525a8

とにかく、これはbetaままで、例外である必要があるとしても、まだ安定していないはずです。 Drop動作が互換性を壊すことなくUnpin依存できる時間がある場合、その時間は今です。

@danielhenrymantilla impl<T> Drop for Vec<T>ような既存の汎用ドロップ実装との互換性の問題をどのように解決するかわかりません。

そうです、別のことが必要です。
Sizedと同じ方法で?Unpinを使用してオプトアウトする、すべてのジェネリックにバインドされた暗黙のT: Unpin Sized

それはそれがなるはずです

impl<T> Drop for Vec<T>
where
  T : Unpin, // implicit, which implies that Vec<T> : Unpin which "upgrades" `Drop` into `PinDrop`

Sizedと同じ方法で?Unpinを使用してオプトアウトする、すべてのジェネリックにバインドされた暗黙のT: Unpin Sized

これはAPI設計全体に大きな影響を及ぼし、 ?Move提案の一部として広く議論されました。 たとえば、ピン留めを機能させるには、多くの既存のライブラリを更新する必要があることを意味します。 結論として、現在入手しているようなライブラリのみのソリューションを使用する方が、これを必要としないため、より優れているということでした。

はい、既存のすべてのライブラリを!Unpin互換に更新する必要があるため、短期的には莫大な費用がかかりますが、長期的には「より安全な」 Dropます。 少なくとも私たちは何も壊していないので、最初はそれほど悪くは見えませんでした。

しかし、それは公正な懸念であり（以前に提起されたことを知りませんでした。指摘していただきありがとうございます、 @ RalfJung ）、短期的な実際的な欠点は、 drop(Pin<&mut Self>)わずかな安全性の向上を上回っているとdrop(Pin<&mut Self>) 。

アドレスでハッシュするPinタイプのHash実装についての議論はありましたか？

Pinは、含まれているポインタに単に委任するHash実装が必要です。アドレスに基づくハッシュの優先順位はありません（値を固定することで方法が変わる理由はわかりません）。ハッシュされます）。