Rust: [안정화] 핀 API

@rfcbot fcp 병합

@withoutboats 팀원이 이것을 병합 할 것을 제안했습니다. 다음 단계는 태그가 지정된 나머지 팀원이 검토하는 것입니다.

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

우려 사항 :

• box-pinnned-vs-box-pin (https://github.com/rust-lang/rust/issues/55766#issuecomment-443371976)
• 문서화 개선 (https://github.com/rust-lang/rust/issues/55766#issuecomment-443367737)
• https://github.com/rust-lang/rust/issues/55766#issuecomment -445074980에 의해 해결 된 고정 해제 이름 지정
• 자체 방법 (https://github.com/rust-lang/rust/issues/55766#issuecomment-443368794)

다수의 검토자가 승인하면 (최대 2 개의 승인이 미결) 최종 댓글 기간이 시작됩니다. 이 과정에서 아직 제기되지 않은 주요 문제를 발견하면 알려주세요!

태그 된 팀원이 나에게 줄 수있는 명령에 대한 정보는 이 문서 를 참조하십시오.

@withoutboats에 대한 자세한 글을 작성해 주셔서 감사합니다! 나는 또한 역사적으로 Pin 의 다양한 보장에 대해 다소 혼란 스러웠으며 현재 여기에서 안전 보장과 관련하여 API가 안정화되는 것에 대해 몇 가지 질문을 받았습니다. 나는 이것을 적어 두려고 노력할 것이라고 생각했지만 내 머리 속에서 이것을 분류하는 것을 돕기 위해.

" Unpin 무엇인가?"라는 벽에 계속 부딪치지 만 이것을 적어 두려고 시도하면서 나는 그것이 무엇인지와 그 주변의 다양한 보장에 대해 다소 혼란 스럽습니다. T 가 Unpin 구현하지 않는다는 것이 무엇을 의미하는지 다시 말씀해 주시겠습니까? 또한, 만약 Unpin 그것을 구현하는 안전한 특성이 순진는 데 사용할 수 있습니다처럼 쉽게의 안전을 보장 훼손 보인다 Pin<T> ,하지만 난 분명히 뭔가를 누락

이 정보가 정확하면 자체 참조가 아닌 모든 유형 (예 : 생성기가 아님)은 고정 해제됩니다.

자기 참조 성뿐만 아니라 Pin 도 지원할 수있는 안정적인 메모리 주소에 대한 다른 사용 사례가 있습니다. 그러나 상대적으로 적고 그 사이에 있습니다.

Unpin 구현하는 것이 안전하다는 것을 이해하는 방법은이를 구현함으로써 작성한 다른 안전하지 않은 코드에 필요한 불변성을 위반할 수 있다는 것입니다 (중요하게는이 안전하지 않은 코드를 작성할 수 있으며 외부 코드는 다음 여부에 의존 할 수 없습니다. Unpin )를 구현했습니다. Unpin 구현 여부에 관계없이 불건전 함을 유발하는 Pin 의 안전한 API로 할 수있는 일은 없습니다. Pin 의 안전하지 않은 API 중 일부를 사용하도록 선택하면 안전 할 때만 Unpin 구현할 수 있습니다. 위의 "고정 및 안전에 대한 참고 사항"섹션의 1 번 항목에서 다룹니다.

흠, 아직도 Unpin 이해가 안 돼요. 나는 처음에는 Unpin 구현하거나 구현하지 않는 것이 무엇을 의미하는지 이해하려고 노력하고 있습니다.

먼저, Unpin 자동으로 구현하는 유형을 아는 것이 도움이 될 것입니다! 위에서 일반적인 포인터 유형 (Arc / Rc / Box / references)이 Unpin 구현한다고 언급했지만 그게 다라고 생각합니까? 이것이 자동 트레이 트인 경우 MyType 유형이 포인터 만 포함하면 Unpin 자동으로 구현한다는 의미입니까? 아니면 다른 유형이 Unpin 자동으로 구현하지 않습니까?

Unpin 보장하는 내용 등을 요약하거나 설명하려고 계속 노력하지만 그렇게하기가 정말 어렵습니다. 누군가 Unpin 구현의 의미와 Unpin 구현하지 않는다는 의미를 다시 반복하여 도움을 줄 수 있습니까?

P::Target 의 인라인 멤버 중 어느 것에서도 이동할 수없는 Pin<P> 의 보장을 이해 한다고 생각 합니다만, 맞습니까?

@alexcrichton 질문

먼저 Unpin을 자동으로 구현하는 유형을 아는 것이 도움이 될 것입니다!

Unpin은 Send 또는 Sync와 같은 자동 특성이므로 대부분의 유형에서 자동으로 구현합니다. 생성기 및 비동기 함수 유형은 !Unpin 입니다. 생성기 또는 비동기 함수 본문을 포함 할 수있는 유형 (즉, 유형 매개 변수가있는 유형)도 유형 매개 변수가없는 한 자동으로 Unpin 아닙니다.

포인터 유형에 대한 명시 적 impls는 유형 매개 변수가 아닌 경우에도 Unpin 를 만드는 것입니다. 이에 대한 이유는이 주석이 끝날 때까지 더 명확해질 것입니다.

누군가 Unpin 구현의 의미와 Unpin 구현의 의미를 다시 반복하여 도움을 줄 수 있습니까?

다음은 고정 API에 대한 기본적인 아이디어입니다. 첫째, 포인터 유형 P , Pin<P> 는 P 처럼 작동하지만 P::Target Unpin 구현하지 않는 한 변경 가능한 역 참조가 안전하지 않습니다. Pin<P> 둘째, Pin 와 관련된 안전하지 않은 코드가 유지해야하는 두 가지 기본 불변성이 있습니다.

• 당신이 안전하지받을 경우 &mut P::Target a에서 Pin<P> , 당신은 이동해서는 안 P::Target .
• Pin<P> 생성 할 수 있다면 소멸자가 실행될 때까지 포인터가 가리키는 데이터에 대한 고정되지 않은 포인터를 얻을 수 없다는 것을 보장해야합니다.

이 모든 것이 의미하는 바는 Pin<P> 를 생성하면 P 이 가리키는 값이 다시는 움직이지 않을 것입니다. 이것은 우리가 자기 참조 구조와 침입에 필요한 보장입니다. 컬렉션. 하지만 유형에 대해 Unpin 만 구현하면이 보장을 거부 할 수 있습니다.

따라서 유형에 대해 Unpin 를 구현하면 해당 유형이 Pin 의 추가 안전 보장을 옵트 아웃하는 것입니다.이를 가리키는 포인터를 가변적으로 역 참조 할 수 있습니다. 이것은 안전하게 사용하기 위해 유형이 움직일 필요가 없다는 것을 의미합니다.

Rc<T> 와 같은 포인터 유형을 이동해도 T 가 포인터 뒤에 있기 때문에 T 는 이동하지 않습니다. 마찬가지로 Rc<T> 포인터를 고정 ( Pin<Box<Rc<T>> )해도 실제로는 T 고정되지 않고 특정 포인터 만 고정됩니다. 이것이 포인터 뒤에 제네릭을 유지하는 모든 것이 제네릭이 아닌 경우에도 Unpin 구현할 수있는 이유입니다.

또한 Unpin이 순진하게 구현하기에 안전한 특성이라면 Pin의 안전하지 않은 보증을 쉽게 훼손하는 데 사용될 수있는 것처럼 보입니다.,하지만 확실히 뭔가 빠졌어요

이것은 고정 API에서 가장 까다로운 부분 중 하나였으며 처음에는 잘못되었습니다.

고정 해제는 "핀에 무언가를 넣은 경우에도 변경 가능한 참조를 얻는 것이 안전합니다."라는 의미입니다. 동일한 액세스 권한을 제공하는 오늘날 존재하는 또 다른 특성이 있습니다 : Drop . 그래서 우리가 알아 낸 것은 Drop 가 안전하기 때문에 Unpin 도 안전해야한다는 것입니다. 이로 인해 전체 시스템이 손상됩니까? 좀 빠지는.

실제로 자기 참조 유형을 구현하려면 안전하지 않은 코드가 필요합니다. 실제로 누구나 신경 쓰는 자기 참조 유형은 컴파일러가 생성하는 유형 인 생성기와 비동기 함수 상태 머신뿐입니다. 다음은 명시 적으로 구현하지 않는 말을 Unpin 그리고 그들은이없는 Drop 당신이 알 수 있도록 당신이이 일단, 이러한 유형의 구현을 Pin<&mut T> , 그들은 것 Unpin 또는 Drop을 구현하지 않는 익명 유형이기 때문에 실제로 변경 가능한 참조를 얻지 못합니다.

미래 결합 자와 같이 이러한 익명 유형 중 하나를 포함하는 구조체가 있으면 문제가 발생합니다. Pin<&mut Fuse<Fut>> 에서 Pin<&mut Fut> 로 이동하려면 "핀 프로젝션" 을 수행해야합니다

이러한 이유로 핀 돌출은 안전하지 않습니다! 고정 불변을 위반하지 않고 고정 프로젝션을 수행하려면 안정화 제안에 나열한 몇 가지 작업을 수행하지 않도록 보장해야합니다.

따라서 tl; dr : Drop 가 존재하므로 Unpin 는 안전해야합니다. 하지만 이것이 모든 것을 망칠 수는 없습니다. 단지 핀 프로젝션이 unsafe 이고 프로젝트를 고정하려는 사람은 불변의 세트를 유지해야한다는 것을 의미합니다.

생성기 및 비동기 함수 상태 머신. 이들은 Unpin을 구현하지 않고 Drop 구현이 없다고 명시 적으로 말합니다. 따라서 이러한 유형의 경우 Pin <& mut T>이 있으면 실제로 변경 가능한 참조를 얻지 못할 것입니다. Unpin 또는 Drop을 구현하지 않는 익명 유형입니다.

비동기 상태 머신에 Drop 구현이 있어야하지 않나요? 비동기 함수의 "스택"에있는 것 (상태 머신의 필드와 같음)은 비동기 함수가 완료되거나 취소 될 때 파괴되어야합니다. 아니면 이런 일이 발생합니까?

나는 무엇을이 상황에서 중요한 것은 여부를 추측 impl Drop for Foo {…} 항목으로 코드를 실행할 것이다 존재 &mut Foo 예를 들어 사용할 수 mem::replace "exfiltrate"로하고, 이동 Foo 가치.

이것은 ptr::drop_in_place 통해 호출 할 수있는 "drop glue"와 동일하지 않습니다. 주어진 Foo 유형에 대한 드롭 글루가 구현 된 경우 Drop::drop 호출 한 다음 각 필드에 대한 드롭 글루를 재귀 적으로 호출합니다. 그러나 이러한 재귀 호출에는 &mut Foo 포함되지 않습니다.

또한 생성기 (및 비동기 상태 머신)에는 사용자 지정 드롭 글루가 있지만 현재 상태를 기반으로 올바른 필드 세트를 드롭하는 것뿐입니다. 드롭 중에 필드를 이동하지 않을 것을 약속합니다.

내가 사용하는 용어 (표준은 없다고 생각하지만) : "drop glue"는 컴파일러가 생성 한 필드의 재귀 적 워킹으로 소멸자를 호출합니다. "드롭 구현"은 Drop 트레이 트의 구현이며 "소멸자"는 드롭 글루와 드롭 구현의 조합입니다. 드롭 글루는 아무것도 움직이지 않으므로 Drop 구현에만 관심이 있습니다.

누군가 미래에 대한 노미 콘 챕터를 작성하고 싶습니까? 이것이 얼마나 미묘한 지 감안할 때 엄청나게 필요한 것 같습니다. 특히 나는 예, 특히 버그가있는 / 나쁜 구현의 예와 그것이 어떻게 불건전한지 알 수 있다고 생각합니다.

@Gankro 물론, 당신은 그것을 위해 나를 내려 놓을 수 있습니다.

설명 해주셔서 감사합니다!

저는 개인적으로 비동기식 Rust와 Pin API를 처음 접했지만, 지난 며칠 동안 조금 놀아 봤습니다 (https://github.com/rust-lang-nursery/futures-rs/pull/1315-여기서 비동기 코드의 침입 컬렉션에 대한 고정을 이용하려고했습니다.)

실험하는 동안 이러한 API에 대해 몇 가지 문제가 발생했습니다.

• 고정의 개념은 안정적인 메모리 주소가 필요하다는 것을 알고 있더라도 완전히 이해하기가 매우 어렵습니다. 내가 직면 한 몇 가지 과제 :
  
  
  
  • 다음과 같은 오류 메시지 :
    
    > 내의 impl core::future::future::Future+futures_core::future::FusedFuture , 형질 std::marker::Unpin 구현되지 std::marker::Pinned
    
    이것은 꽤 재귀적이고 모순적으로 들립니다 (고정 된 것이 고정되지 않은 이유는 무엇입니까?)
  
  
  • 핀을 매개 변수로 사용하는 메서드에서 변경 가능한 필드에 어떻게 액세스 할 수 있습니까? 2 개의 안전하지 않은 방법을 사용하여 필요한 작업을 수행하는 솔루션에 도달 할 때까지 약간의 검색, 새로운 용어 ( Pin 투영)에 대해 배우고 pin-utils 에서 메서드를 복사하려고했습니다. .
  
  
  • async 방법과 select 사례에서 어떻게 내 미래를 실제로 사용할 수 있습니까? 선물 스택에 pin_mut!() 필요하다는 것이 밝혀졌습니다. 실제로 스택이 아니기 때문에 혼란 스럽습니다.
  
  
  • 왜 않습니다 drop() 방법은 이제 다시 걸릴 &mut self 대신의 Pin .
  
  
  • 전반적으로 그것은 컴파일 할 것을 얻기 위해 안전하지 않은 고정 관련 API를 무작위로 사용하는 느낌이었습니다. 이것은 확실히 이상적인 상황이 아니 었습니다. 나는 다른 사람들이 비슷한 일을 시도 할 것이라고 생각합니다.
  
  
• 이 개념은 코드베이스 전체에 많이 전파되어 많은 사람들이 실제로 Pin 및 Unpin 가 무엇인지 이해하도록하는 것처럼 보입니다. 이것은 좀 더 특별한 사용 사례에 대한 구현 세부 정보가 약간 누출 된 것처럼 보입니다.
• 핀은 수명과 다소 관련이있는 것 같지만 다소 직교합니다. 기본적으로 Pin은 drop() 가 호출 될 때까지 정확히 동일한 주소를 가진 객체를 다시 볼 수 있음을 알려줍니다. 현재 범위와 'static 사이에 일종의 가상 수명을 제공합니다. 관련이 있지만 여전히 완전히 다른 두 가지 개념을 갖는 것은 혼란스러워 보입니다. 'pinned 와 같은 것으로 모델링 할 수 있는지 궁금했습니다.

컴파일 할 때 나는 종종 C ++에 대해 생각했습니다. 이러한 문제의 대부분은 피할 수 있습니다. 유형은 이동 생성자와 할당 연산자를 삭제하여 이동 불가능으로 선언 할 수 있습니다. 유형이 이동할 수없는 경우 해당 유형을 포함하는 유형도 이동할 수 없습니다. 따라서 속성 및 요구 사항은 기본적으로 유형 계층 구조를 통해 흐르고 일부 호출 내에서 속성을 전달하는 대신 컴파일러에 의해 확인됩니다 (예 : drop() 아님). 이해하기 훨씬 쉽다고 생각합니다. 그러나 Future 는 폴링을 시작하기 전에 현재 자주 이동해야하므로 Rust에는 적용되지 않을 수 있습니다. 그러나 다른 한편으로는 그 특성을 가진 새로운 정의 또는 움직임과 투표 단계를 분리하여 수정할 수 있습니다.

Alex Unpin 코멘트에 관하여 : 저는 Unpin 의미를 천천히 이해하고 있지만 이해하기 어렵다는 데 동의합니다. 다른 이름이 도움이 될 수도 있지만 지금은 간결한 이름을 찾을 수 없습니다. ThingsInsideDontBreakIfObjectGetsMoved , DoesntRequireStableAddress , PinDoesntMatter 등

내가 아직 완전히 이해하지 못한 것은 왜 &mut self 에서 Pin<&mut self> 를받는 것이 모든 유형에 대해 안전 할 수 없는지입니다. Pin이 단지 객체 자체의 주소가 안정적이라는 것을 의미한다면, 이것은 대부분의 전형적인 Rust 유형에 적용됩니다. Pin에 통합 된 또 다른 우려가있는 것 같습니다. 내부의 자체 참조 유형도 깨지지 않는다는 것입니다. 이러한 유형의 경우 Pin 받은 후 조작하는 것은 항상 안전하지 않습니다. 그러나 대부분의 경우 컴파일러에서 생성되며 안전하지 않거나 원시 포인터도 괜찮을 것이라고 생각합니다. 고정 된 호출을 하위 필드로 전달해야하는 수동 향후 결합 자의 경우 필드를 폴링하기 전에 필드에 핀을 생성하는 안전하지 않은 호출이 분명히 필요합니다. 그러나이 경우에는 전혀 중요하지 않은 다른 필드에 액세스하는 것보다 실제로 중요한 장소 (핀이 여전히 유효합니까?)와 더 관련이있는 위험을 봅니다.

내가 가진 또 다른 생각은 몇 가지 제한 사항이 적용되면 더 간단한 시스템을 얻을 수 있는지 여부입니다. 예를 들어 고정이 필요한 것이 비동기 메서드 내에서만 사용할 수 있고 향후 결합 자와 함께 사용할 수없는 경우입니다. Pin 또는 Unpin 중 하나로 단순화 할 수 있습니다. 많은 코드의 경우 선택 / 조인 지원이있는 비동기 / 대기 메서드가 결합 자에게 유리할 수 있다는 점을 고려할 때 이것은 가장 큰 손실이 아닐 수 있습니다. 그러나 이것이 정말로 도움이되는지에 대해서는 충분히 생각하지 않았습니다.

긍정적 인 측면 : "스택"차용으로 비동기 / 대기 코드를 작성할 수 있다는 것은 매우 멋지고 필요합니다! 그리고 침입 컬렉션과 같은 다른 사용 사례에 대해 고정을 사용하는 기능은 임베디드 시스템이나 커널과 같은 대상뿐 아니라 성능에도 도움이됩니다. 그래서 나는 이것에 대한 해결책을 정말로 고대하고 있습니다.

안정화 보고서에 대한 사소한 문제 :

fn get_unchecked_mut(self) -> &'a mut T

나는 이것이 실제로 unsafe fn 라고 생각합니다.

@ Matthias247 T가 고정 해제되지 않은 경우 Pin<P<T>> 에서 & mut T를 안전하게 가져올 수 없습니다. 그러면 mem::swap 을 (를) Pin에서 T를 이동시켜 고정하는 목적을 무력화 할 수 있기 때문입니다.

내가 나 자신에게 설명하는 데 어려움이있는 한 가지는 핀이 API의 일부가되어야한다는 점에서 Future를 다른 특성과 근본적으로 다르게 만드는 이유입니다. 내 말은, async / await에 고정이 필요하기 때문이라는 것을 직관적으로 알고 있지만, Iterators와는 다른 Futures에 대해 구체적으로 말합니까?

폴링은 & mut self를 취하고 Pin<P> 유형 또는 고정 해제 된 유형에 대해서만 Future를 구현할 수 있습니까?

핀을 매개 변수로 사용하는 메서드에서 변경 가능한 필드에 어떻게 액세스 할 수 있습니까?

이것은 실제로 Pin 에 몇 가지 누락 된 메서드가 있는지 궁금합니다.

impl<'a, T: ?Sized> Pin<&'a T> {
    fn map<U: Unpin, F: FnOnce(&T) -> &U>(self, f: F) -> Pin<&'a U>
}

impl<'a, T: ?Sized> Pin<&'a mut T> {
    fn map<U: Unpin, F: FnOnce(&mut T) -> &mut U>(self, f: F) -> Pin<&'a mut U>
}

pin_utils::unsafe_unpinned! 매크로에서 사용할 수 있습니다.

이 매크로가 안전하지 않다고 주장하는 _why_를 해결하려고합니다. !Unpin 이고 Unpin 필드가있는 경우이 필드에 투영하는 것이 안전하지 않은 이유는 무엇입니까?

내가 불건전하다는 것을 알 수있는 유일한 상황은 !Unpin 유형을 구현하여 self의 Unpin 필드에 대한 원시 포인터를 가져 오는 것입니다 (그리고 안정적인 주소 / 동일한 인스턴스), &mut 를 동일한 필드로 가져와 외부 함수에 전달합니다. 이것은 Unpin 구현이 안전한 이유와 동일한 이유에 해당하는 것 같습니다. !Unpin 의 필드에 대한 원시 포인터를 사용하여 일부 금고를 호출 할 수 없도록 선택합니다. 아피스.

이전 상황을 더 안전하게 만들기 위해 Pinned 추가하는 대신 일반적으로 구조체의 Unpin 필드가 실제로 !Unpin 표시를 위해 Pinned 에 빌드 된 래퍼가있을 수 있습니다. Pinned 구조체 전체에 :

pub struct MustPin<T: Unpin>(T, Pinned);

impl<T: Unpin> MustPin<T> {
    pub const fn new(t: T) -> Self { ... }
    pub fn get(self: Pin<&Self>) -> *const T { ... }
    pub fn get_mut(self: Pin<&mut Self>) -> *mut T { ... }
}

이 모든 것이 현재 API와 역 호환되는 것처럼 보이며 futures-rs 결합 자에서 일부 안전하지 않은 부분을 제거 할 수 있지만 (예 : 이와 같은 추가 필드에 안전하게 액세스 할 수 있습니다) 현재 사용 사례에는 필요하지 않습니다. 사용자 정의 !Unpin 유형 (예 : 침입 컬렉션)을 구현하기 위해 이와 같은 일부 API를 실험하고 나중에 추가 할 수 있습니다.

내가 수 있기 때문에 Nemo157 @ 그지도 기능은 안전하지 mem::swap 온 &mut T 기능 반환하기 전에 저를 통과 &mut U . (변하기 쉬운 것은 불변하는 것이 안전하지 않을 수도 있다는 것입니다)

편집 : 또한 pin-utils 매크로가 다릅니다. unsafe_unpinned 대상 유형이 Unpin 인 것과 관련이 없습니다. "고정되지 않은 투영"- &mut Field 대한 투영입니다 !Unpin 경우에도 해당 필드에 프로젝트를 고정하지 않는 한 안전하게 사용할 수 있습니다.

내가 나 자신에게 설명하는 데 어려움이있는 한 가지는 핀이 API의 일부가되어야한다는 점에서 Future를 다른 특성과 근본적으로 다르게 만드는 이유입니다. 내 말은, async / await에 고정이 필요하기 때문이라는 것을 직관적으로 알고 있지만, Iterators와는 다른 Futures에 대해 구체적으로 말합니까?

이론적 인 차이는 없지만 실용적인 차이가 있습니다. 하나는 Iterator 이 안정적입니다. 그러나 결과적으로 우리가 매우 영리한 것을 알아 내지 않는 한, 그것이 없이는 완전히 안전해야하지만 이중 간접없이 자기 참조 생성기에서 for 루프를 실행할 수 없습니다. for 루프는 생성기를 소비하고 절대 이동하지 않기 때문입니다).

또 다른 중요한 실용적인 차이점은 Iterator 와 Future 사이의 코드 패턴이 상당히 다르다는 것입니다. 미래의 대기 지점을 빌리고 싶지 않고 10 분을 갈 수 없습니다. 그래서 선물 0.1에서이 Arc 가 여기 저기 나타나는 것을 볼 수 있으므로 두 개의 다른 변수에서 동일한 변수를 사용할 수 있습니다. and_then 통화. 그러나 우리는 전혀 자기 참조 반복자를 표현할 수없이 아주 멀리 왔, 그건 그냥 사용 사례 중요한 것을.

내가 할 수 있기 때문에 그지도 기능은 안전하지 mem::swap 온 &mut T 함수가 반환하기 전에 저를 통과 &mut U

아, 젠장, 그것의 그 부분을 잊어 버렸습니다.

fn as_mut(&mut self) -> Pin<&mut P::Target> fn into_ref (self)-> Pin <& 'a T>`

참조를 실제로 반환하는 메서드와 혼동하지 않으려면 as_pinned_mut 및 into_pinned_ref 호출해야합니까?

표준에서 Unpin의 주목할만한 구현 :

impl<P> Unpin for Pin<P> {} 있습니다. 우리가 사용하는 유형의 경우 이것은 효과가 없으며 조금 더 안전 해 보입니다.
신경 쓰지 마세요. 목록에 있습니다. ;)

드롭 보장

안정화 전에 Drop 보증을 성문화해야한다고 생각합니다. 그렇지 않으면 너무 늦을 것입니다.

고정 된 객체 (대상의 스토리지 무효화 불법 Pin 호출하지 않고 참조) drop 개체에 대해.

여기서 "무효화"는 "할당 취소"를 의미 할 수 있지만 "재용도"도 의미합니다. x 을 Ok(foo) 에서 Err(bar) 로 변경하면 foo 의 저장 용량이 무효화됩니다. .

이것은이 할당 해제 불법가되도록, 예를 들어 결과를 갖는 Pin<Box<T>> , Pin<Rc<T>> 또는 Pin<Arc<T>> 제 호출없이 drop::<T> .

Deref , DerefMut 용도 변경

나는 이것이 Deref 특성을 "이것이 똑똑한 포인터이다"를 의미하는 방식으로 어떻게 재활용하는지에 대해 여전히 약간 불안해합니다. 우리는 "상속"과 같은 다른 것들에도 Deref 를 사용합니다. 그것은 안티 패턴 일 수 있지만 여전히 상당히 일반적으로 사용되고 있으며 솔직히 유용합니다. :디

나는 이것이 건전성 문제가 아니라고 생각합니다.

Unpin 이해

뻔뻔한 플러그 : 나는 이것에 대해 두 개의 블로그 게시물을 썼는데, 이것은 당신이 (반) 형식적인 구문을 얼마나 좋아하는지에 따라 도움이 될 수도 있고 아닐 수도 있습니다. ;) API는 그 이후로 변경되었지만 기본 아이디어는 변경되지 않았습니다.

• 고정에 대한 공식적인 모습
• 고정을 통한 안전한 침입 컬렉션

안전한 핀 돌출부

@ Matthias247 나는 당신이 겪고있는 한 가지 문제는 현재 고정과 관련된 추상화를 구축하려면 거의 항상 안전하지 않은 코드가 필요하다는 것입니다. 이러한 추상화를 사용 하는 것은 좋지만 예를 들어 안전한 코드에서 미래의 결합자를 정의 하는 것은 작동하지 않습니다. 그 이유는 "핀 프로젝션"에는 컴파일러 변경으로 만 안전하게 확인할 수있는 제약 조건이 있기 때문입니다. 예를 들어

내 drop () 메서드가 이제 Pin 대신 & mut self를 다시받는 이유는 무엇입니까?

음, drop() 은 오래되었습니다. Rust 1.0부터 존재하므로 변경할 수 없습니다. Pin<&mut Self> 하면 Unpin 유형이 지금처럼 &mut 얻을 수 있지만, 이는 이전 버전과 호환되지 않는 변경입니다.

미래의 결합자를 안전하게 작성하려면 안전한 핀 프로젝션이 필요하며이를 위해 컴파일러를 변경해야하므로 라이브러리에서 수행 할 수 없습니다. derive proc_macro에서 거의 할 수 있지만 "이 유형에는 Drop 또는 Unpin 구현이 없습니다"라고 주장하는 방법이 필요합니다.

핀 프로젝션을 위해 이러한 안전한 API를 얻는 방법을 알아내는 것이 가치가 있다고 생각합니다. 그러나 이것이 안정화를 차단할 필요는 없습니다. 여기서 안정화하는 API는 안전한 핀 프로젝션과 호환되어야합니다. ( Unpin 은 위의 주장을 구현하기 위해 lang 항목이되어야 할 수도 있지만 그렇게 나쁘게 보이지는 않습니다.)

고정은 아닙니다 !

나는 종종 C ++에 대해 생각했는데, 이러한 문제의 대부분을 피할 수 있습니다. 유형은 이동 생성자와 할당 연산자를 삭제하여 이동 불가능으로 선언 할 수 있습니다. 유형이 이동할 수없는 경우 해당 유형을 포함하는 유형도 이동할 수 없습니다.

Rust에 대해 움직일 수없는 유형을 정의하려는 시도가 여러 번있었습니다. 매우 빠르게 복잡해집니다.

이해해야 할 한 가지 중요한 점은 고정이 움직일 수없는 유형을 제공하지 않는다는 것입니다! 모든 유형은 Rust에서 움직일 수 있습니다. T 가있는 경우 원하는 곳으로 이동할 수 있습니다. 이동할 수없는 유형 대신, 우리는 이동할 수없는 포인터 유형을 정의하기 때문에 새로운 캡슐화 된 API를 정의하는 Rust의 기능을 사용 T )가 아니라 포인터 유형 ( Pin<&mut T> T )에 있습니다. 유형이 "나는 결코 움직일 수 없습니다"라고 말할 방법이 없습니다. 그러나, 유형 "나는 고정있어 경우, 나를 다시 이동하지 않습니다 '라고 할 수있는 방법이있다. 따라서 내가 소유 한 MyFuture 는 항상 이동할 수 있지만 Pin<&mut MyFuture> 는 더 이상 이동할 수없는 MyFuture 의 인스턴스에 대한 포인터입니다.

이것은 미묘한 요점이며, 우리는이 일반적인 오해를 피하기 위해 여기에서 문서를 구체화하는 데 시간을 할애해야 할 것입니다.

그러나 우리는 자기 참조 반복자를 전혀 표현할 수없는 상태로 꽤 멀리 왔으며, 사용 사례에서 그다지 중요하지 않습니다.

지금까지 모든 반복기가 유형과 impl Iterator for … 블록을 사용하여 정의 되었기 때문입니다. 두 반복 사이에 상태를 유지해야하는 경우 반복기 유형의 필드에 상태를 숨기고 &mut self 작업하는 것 외에는 선택의 여지가 없습니다.

그러나 이것이 언어에 제너레이터를 포함시키는 주된 동기가 아니더라도 결국 제너레이터 yield 구문을 사용하여 for 와 함께 사용할 수있는 것을 정의 할 수 있다면 매우 좋을 것입니다 yield 에서 차용하십시오. 왜냐하면 발전기-미래의 경우만큼이나 발전기-반복자에게도 중요하기 때문입니다.

( Unpin 은 위의 주장을 구현하기 위해 lang 항목이되어야 할 수도 있지만 그렇게 나쁘지 않은 것 같습니다.)

Unpin 및 Pin 은 (는) 안전한 부동 생성기를 지원하기 위해 이미 lang 항목이어야합니다.

모든 설명에 감사드립니다! 나는 @Gankro 와 Pin 에 관한 nomicon 스타일의 장이 여기에서 매우 유용 할 것이라는 데 동의합니다. 다양한 안전한 방법이 존재하는 이유와 안전하지 않은 방법이 왜 안전하지 않은지에 대한 많은 개발 역사가 있다고 생각합니다.

이를 이해하는 데 도움이되도록 각 기능이 안전한 이유 또는 unsafe 이유를 다시 적어보고 싶었습니다. 위의 이해를 바탕으로 다음을 모두 얻었지만 여기 저기에 몇 가지 질문이 있습니다. 다른 사람들이 내가 이것을 채우도록 도울 수 있다면 좋을 것입니다! (또는 내 생각이 잘못된 부분을 지적하도록 도와주세요)

• fn new(P) -> Pin<P> where P: Deref, P::Target: Unpin

  • 이것은 Pin<P> 를 생성하는 안전한 방법이며
    Pin<P> 일반적으로 P::Target 가
    프로그램에서 P::Target 는 Unpin 를 구현합니다.
    Pin 더 이상 보류하지 않습니다. "결과적으로 안전은
    유지를 보장하므로 모든 것이 평소처럼 진행될 수 있습니다.

• unsafe fn new_unchecked(P) -> Pin<P> where P: Deref

  • 이전과는 달리,이 기능은 unsafe 때문에 P 되지 않습니다
    반드시 Unpin 구현해야하므로 Pin<P> 는
    P::Target 는 Pin<P> 가 생성 된 후 다시는 이동하지 않습니다.

  이 보증을 위반하는 사소한 방법은이 기능이 안전하다면
  처럼:

  fn foo<T>(mut a: T, b: T) {
      Pin::new_unchecked(&mut a); // should mean `a` can never move again
      let a2 = mem::replace(&mut a, b);
      // the address of `a` changed to `a2`'s stack slot
  }
  

  따라서 Pin<P> 실제로 의미하는 바를 보장하는 것은 사용자에게 달려 있습니다.
  P::Target 는 공사 후에 다시는 이동되지 않으므로 unsafe !

• fn as_ref(&Pin<P>) -> Pin<&P::Target> where P: Deref

  • Pin<P> 가 주어지면 P::Target 가 절대 움직이지 않을 것이라는 보장이 있습니다. 그건
    Pin 계약의 일부입니다. 결과적으로 그것은
    &P::Target , P::Target 대한 또 다른 "스마트 포인터"는 동일한 정보를 제공합니다.
    따라서 &Pin<P> 는 Pin<&P::Target> 로 안전하게 변환 할 수 있습니다.

  Pin<SmartPointer<T>> 에서 Pin<&T> 로 이동하는 일반적인 방법입니다.

• fn as_mut(&mut Pin<P>) -> Pin<&mut P::Target> where P: DerefMut

  • 여기의 안전은 위의 as_ref 와 거의 같다고 생각합니다.
    우리는 변경 가능한 액세스 권한을 제공하지 않고 Pin 만 제공하므로 쉽게 할 수있는 것은 없습니다.
    아직 위반했습니다.

  질문 : "악성" DerefMut impl은 어떻습니까? 이것은 안전한 방법입니다
  사용자가 제공 한 DerefMut 를 호출하기 위해 기본적으로 &mut P::Target 상자,
  아마도 그것을 수정할 수 있습니다. 이게 안전 해요?

• fn set(&mut Pin<P>, P::Target); where P: DerefMut

  • 질문 : Pin<P> (그리고 우리가
    Unpin ), P::Target 가 움직이지 않는다는 보장이되지 않나요? 만약 우리가 할 수 있다면
    다른 P::Target 로 다시 초기화하십시오. 안전하지 않습니까?
    아니면 이것이 소멸자와 관련이 있습니까?

• unsafe fn map_unchecked<U, FnOnce(&T) -> &U>(Pin<&'a T>, f: F) -> Pin<&'a U>

  • 이것은 unsafe 함수이므로 여기서 주요 질문은 "왜 이건
    안전한 경우 보증 위반의 예는 다음과 같습니다.

  ...

  질문 :: 여기서 반례는 무엇입니까? 이것이 안전하다면 무엇입니까
  Pin 의 보증 위반을 보여주는 예?

• fn get_ref(Pin<&'a T>) -> &'a T

  • Pin<&T> 의 보장은 T 가 절대 움직이지 않음을 의미합니다. &T 반환
    T 변형을 허용하지 않으므로 유지하는 동안 안전해야합니다.
    이 보증.

  여기서 하나의 "아마도 문제"는 내부 변경 가능성입니다. T 가
  RefCell<MyType> ? 그러나 이것은 보장을 위반하지 않습니다
  Pin<&T> 보장은 T 전체에 적용되며
  인테리어 필드 MyType . 내부 변경 가능성은 이동할 수 있지만
  내부적으로는 여전히 근본적으로 전체 구조를 이동할 수 없습니다.
  & 참조.

• fn into_ref(Pin<&'a mut T>) -> Pin<&'a T>

  • Pin<&mut T> 는 T 가 움직이지 않음을 의미합니다. 결과적으로 Pin<&T>
    동일한 보증을 제공합니다. 이 변환에 큰 문제가되지 않아야합니다.
    대부분 유형을 전환합니다.

• unsafe fn get_unchecked_mut(Pin<&'a mut T>) -> &'a mut T

  • Pin<&mut T> 는 T 가 절대 움직이지 않아야 함을 의미하므로 이것은 간단하게 unsafe
    결과에 mem::replace 를 사용하여 T 안전하게 이동할 수 있기 때문입니다. 그만큼
    unsafe 여기 "내가 &mut T 주지만, 당신은 절대로
    T "이동.

• unsafe fn map_unchecked_mut<U, F: FnOnce(&mut T) -> &mut U>(Pin<&'a mut T>, f: F) -> Pin<&'a mut U>

  • 여기서 unsafe 는 기본적으로 최소한 위와 동일하다고 생각합니다.
    안전하게 &mut T 나눠줍니다 (안전하지 않은 폐쇄를 요구할 수 없음).
    mem::replace 와 함께 쉽게 사용할 수 있습니다. 여기에도 다른 위험이있을 수 있습니다.
    하지만 적어도 안전하지 않다는 것이 합리적으로 보입니다.
    그것 덕분에.

• fn get_mut(Pin<&'a mut T>) -> &'a mut T where T: Unpin

  • Unpin 를 구현하면 " Pin<&mut T> 에는 보장이 없습니다.
    &mut T "의 newtype 래퍼입니다. 결과적으로
    유지하면 &mut T 안전하게 반환 할 수 있습니다.

• impl<P: Deref> Deref for Pin<P> { type Target = P::Target }

  • as_ref 다음에 get_ref 를 사용하여 안전하게 구현할 수 있으므로
    이 impl의 안전성은 위와 같습니다.

• impl<P: DerefMut> DerefMut for Pin<P> where T::Target: Unpin { }

  • as_mut 다음에 get_mut 를 사용하여 안전하게 구현할 수 있으므로
    이 impl의 안전성은 위와 같습니다.

• impl<T: ?Sized> Unpin for Box<T> (및 기타 포인터 관련 구현)

  • 다른 조치가 취해지지 않으면 Box<T> 는 Unpin 트레이 트를 구현합니다.
    T 구현 Unpin . 여기에서이 구현은
    T 명시 적으로 Unpin 구현하지 않으면 Box<T> 는 Unpin 구현합니다.

  질문 : 이것이 근본적으로 힘을 실어주는 것에 대한 예는 무엇입니까?
  
  예를 들어,이 impl이 있다면 unsafe 가 필요할 수있는 금고는
  
  존재하지 않았습니다.

@ Matthias247 Pin에서 & mut T를 안전하게 가져올 수 없습니다.

> T가 고정 해제가 아닌 경우 mem :: swap을 사용하여 T를 Pin에서 이동할 수 있습니다. 그러면 고정 목적이 무효화됩니다.

감사! 예, swap 는 안전하지 않은 방법이 아니므로 분명히 문제가됩니다. 하지만 Unpin 바인딩을 swap() 에 추가하여 문제를 해결할 수 있습니까? 지금까지의 모든 코드는 Unpin 이거나 어쨌든 안전하지 않기 때문에 아무 것도 깨뜨려서는 안됩니다.

여전히 저를 가장 혼란스럽게하는 것 중 하나는 Pin<T> 여러 보증을 코드화한다는 것입니다. T의 주소가 안정적이라는 것과 내부 상태에 대한 일부 보증 (일부에서는 고정 / 불변 상황이지만 실제로는 아닙니다).

안전하지 않은 코드 / 프로젝션을 Pin 기반 호출이 더 필요한 곳 ​​(예 : 필드의 poll s)으로 이동하는 것이 안전하지 않은 프로젝션을 처리하는 것보다 더 나을 수 있습니다. 모든 경우. 그러나 이제 또 다른 문제가 있음을 깨달았습니다. 변경 가능한 참조에 대한 액세스 권한이있는 코드는 필드를 자유롭게 이동할 수 있으며이 필드에서 drop() 를 안전하게 호출하면 다른 곳에 저장되는 주소. 이를 위해 언급 된 drop(Pin<T>) 오버로드가 필요합니다.

@RalfJung 설명 주셔서 감사합니다! 나는 일반적으로 안전하지 않은 일을 확실히하려고했기 때문에 추가적인 이해가 필요하다는 사실에 동의합니다. 나는 더 일반적으로 안전한 미래의 결합자를 작성하고 싶어하는 사람들에 대해 더 걱정하지만 지금은 이러한 모든 용어에 직면하게 될 수도 있습니다. 만약 그들이 Unpin 와 핀 프로젝션을 전혀 이해하지 않고도 결합자를 작성할 수 있고, 그런 다음 감소 된 방식으로 작동하는 결합 자만 얻을 수 있다면 ( Unpin 선물에서만), 그것은 바람직해 보입니다. 나는 그것을 시도하지 않았기 때문에 나는 그것이 현재 사례인지 말할 수 없다. 적어도 Unpin 경계를 수동으로 추가해야한다고 생각합니다.

비 이동형과 핀형이 다르다는 것도 알고 있습니다. 그러나 나는 현재 차이점보다 유스 케이스에 더 집중하고 있습니다. 그리고 침입 컬렉션의 사용 사례의 경우 이동 불가능한 유형은 너무 복잡하지 않고 매우 잘 작동합니다. 미래의 경우 이동식 유형에서 비 이동식 유형으로의 방식이 누락 되었기 때문에 분명히 일부 연구가 필요할 것입니다. 그 방법이 Pin API보다 인체 공학적이지 않다면 승리도 없을 것입니다.

T: Unpin 을 mem::swap 에 추가하면 특정 유형이 핀 내부에 있지 않더라도 사용할 수 없습니다.

그러나 swap ()에 Unpin 바인딩을 추가하여 해결할 수 있습니까? 지금까지의 모든 코드는 고정 해제이거나 어쨌든 안전하지 않기 때문에 아무 것도 깨지지 않아야합니다.

그것은 모든 일반적인 코드를 깨뜨릴 것입니다 : 만약 당신이 제약없이 T 대한 오늘날의 stable rust에서 함수를 작성한다면, 그것에 대해 swap 를 호출 할 수 있습니다. 이것은 계속 작동해야합니다.

이동 불가능한 유형은 너무 복잡하지 않고 잘 작동합니다.

아무도 여기서 안정화를 위해 제안 된 것보다 훨씬 복잡하지 않고 이전 버전과 호환되는 방식 으로 Rust https://github.com/rust-lang/rfcs/pull/1858 을 참조

https://github.com/rust-lang/rfcs/pull/2349 의 RFC와 여기에서 시작하는 보트의 블로그 시리즈는 고려 된 다른 디자인에 대한 배경과 인상을주는 데 도움이 될 것입니다. (날짜도 주목하세요.이 디자인은 거의 10 개월 동안 작업 중입니다!)

또한 mem :: swap은 전혀 흥미로운 기능이 아니기 때문에 붉은 청어입니다. 말 그대로 그냥

let temp = *a; 
*a = *b; 
*b = temp;

@Gankro 는 안전하지 않은 코드를 사용하지 않습니까? Afaik 문자 그대로 쓸 수 없습니다.

편집 : 이것에 대해 생각하는 또 다른 방법은 mem::swap T: Unpin 를 추가하는 것이 실제로 언어 수준에서 안전의 정의를 변경하는 것입니다. 그것은 야생에서 모든 mycrate::swap fns를 깨뜨릴 것입니다.

T : Unpin to mem :: swap을 추가하면 특정 유형이 Pin 안에 있지 않더라도 사용할 수 없습니다.

고정 해제가 자동으로 파생되면 ( Sync / Send 와 같은 방식으로) 문제가되지 않는다고 생각했습니다.

그것은 모든 일반적인 코드를 깨뜨릴 것입니다 : 제약없이 T에 대한 오늘날의 stable rust에서 함수를 작성한다면, 그것에 대해 swap을 호출 할 수 있습니다. 이것은 계속 작동해야합니다.

그러나 이것은 분명합니다. 특성 경계가 Rust에서 명시 적으로 전파되어야한다는 사실에 대해 생각하지 않았습니다.

아무도 여기서 안정화를 위해 제안 된 것보다 훨씬 복잡하지 않고 이전 버전과 호환되는 방식으로 Rust에 이동 불가능한 유형을 추가하는 방법을 보여주지 않았습니다. RFC 리포지토리에서 이러한 오래된 제안 및 토론 중 일부를 찾을 수 있습니다. 한 가지 예는 rust-lang / rfcs # 1858을 참조하세요.

감사합니다. 시간이 있으면 이전 작업에 대해 좀 더 읽어 보겠습니다. 분명히 많은 생각과 노력이 이미 여기에 들어갔고 나는 확실히 물건을 차단하고 싶지 않습니다. 이 작업을 시도 할 때 내 우려 사항과 질문을 제공하고 싶었습니다.

안녕하세요.

고정 해제가 자동으로 파생되면 (동기화 / 보내기와 동일한 방식으로) 문제가되지 않는다고 생각했습니다.

내가 분명했는지 잘 모르겠습니다. 명확히하기 위해 !Unpin 유형을 이동하는 것이 완벽하게 안전하므로 mem::swap 유형을 이동하는 것이 완벽하게 안전합니다. T: !Unpin 유형을 고정한 후, 즉 Pin<P<T>> 내부에서 이동하는 것은 안전하지 않습니다.

예를 들어, async / await 코드에서 원하는만큼 비동기 함수에서 반환 된 Future를 이동할 수 있습니다. pin_mut! 또는 Pin<Box<..>>> 또는 기타 항목에 넣으면 이동이 중지됩니다.

이에 대해 몇 가지 질문이 있습니다.

1. 의 중요성을 감안 Pin<T> 대 async 녹의 다른 부분과 상호 작용할 때 unsoundness 용 발전기 및 잠재력 (예 swap & replace ), 모든 보유 여기에 제안 된 고정 API 변형에 대해 공식 검증 (예 : @jhjourdan 또는 @RalfJung)이 수행 되었습니까?

2. 이 API가 Rust의 추상 기계 / 운영 의미론에 대한 새로운 보장을 제공합니까? 즉, async 및 await / 발전기에 대한 지원 메커니즘으로 사용 사례를 잊어 버린 경우이를 생태계의 크레이트 안에 넣을 수 있으며 현재 보증이 주어진 경우에만 작동합니다. 주기?

3. 고정 API를 안정화 한 결과 어떤 종류의 API 또는 유형 시스템 추가가 불가능합니까? (이 질문은 2의 확장입니다.)

4. 안정화 될 API가 필드 프로젝션을 개선하기 위해 &pin T 유형을 제공하는 언어를 발전시키는 측면에서 제공하는 방법은 무엇입니까 (제안 된 API로는 좋지 않은 것 같습니다).

몇 가지 메모가 있습니다.

1. 표준 라이브러리의 문서는 매우 드물게 보입니다. :(

2. 나는 고정 구조가 정신적으로 매우 부담스럽고 ​​복잡하다는 데 다른 사람들과 동의합니다.

3. 문서의 Unmovable 예제는 지나치게 복잡해 보이며 unsafe ; 이것은 차선책으로 보입니다. 언어의 RFC 초안에 자세히 설명 된 점진적 초기화 (즉, NLL 개선)는 대신 다음을 제공 할 수 있습니다.

struct Unmovable<'a> {
    data: String,
    slice: &'a str,
}

let um: Unmovable<'_>;
um.data = "hello".to_string();
um.slice = &um.data; // OK! we borrow self-referentially.

drop(um); // ERROR! `um.slice` is borrowing `um.data` so you cannot move `um`.

// You won't be able to take a &mut reference to `um` so no `swap` problems.

여기에는 안전하지 않은 제로가 포함되며 사용자가이를 처리하기가 매우 쉽습니다.

또한 std API는 객체를 스택에 고정하는 안전한 방법을 제공하지 않습니다.
함수 API를 사용하여 안전하게 구현할 수있는 방법이 없기 때문입니다.

이와 같은 API는 어떻습니까?

pub fn using_pin<T, R, F>(value: T, f: F) -> R
where F: for<'a> FnOnce(Pin<&'a mut T>) -> R {
    pin_mut!(value);    // Actual implementation inlines this but the point is this API is safe as long as pin_mut! is safe.
    f(value)
}

나는 고정 API의 개발을 너무 밀접하게 따르지 않았기 때문에 다른 곳에서 언급되거나 설명되었을 수 있으며 찾을 수 없었습니다. 그렇다면 사과드립니다.

Pinned 유형은 Unpin 구현하지 않는 ZST입니다. 그것은 당신이 할 수 있습니다
stable에서 Unpin 의 자동 구현을 억제합니다. 여기서 !Unpin impls
아직 안정적이지 않을 것입니다.

!Unpin impls를 안정적으로 만들 수없는 이유에 대한 설명이 있습니까?

Foo (포함 유형)가 repr (packed)되지 않은 경우에만 안전합니다.
이로 인해 필드가 이동되어 재정렬됩니다.

패킹은 필드를 동적으로 이동할 수 있음을 의미합니까? 그것은 약간 무섭습니다. llvm이 다른 상황에서 필드를 이동하는 코드를 생성하지 않을 것이라고 확신합니까? 마찬가지로 스택의 고정 된 값이 llvm에 의해 이동 될 수 있습니까?

미묘함에도 불구하고 이것은 정말 멋진 API처럼 보입니다. 잘 했어!

@Centril Ralf는 자신의 블로그 에 고정

핀 API는 언어 변경을 전혀 포함하지 않으며 기존 언어 기능을 사용하여 표준 라이브러리에서 완전히 구현됩니다. Rust 언어에 영향을 미치지 않으며 다른 언어 기능에 대해 차감하지 않습니다.

Pin 은 Rust의 가장 귀중하고 고전적인 기능 중 하나 인 API unsafe 일부를 표시하여 API에 불변성을 도입하는 기능을 현명하게 구현 한 것입니다. Pin 포인터를 래핑하여 하나의 작업 ( DerefMut )을 안전하지 않게 만들고이를 수행하는 사람들이 특정 불변을 유지하도록 요구하고 (참조에서 벗어나지 않음) 다른 코드가 이것이 결코 일어나지 않을 것이라고 가정하십시오. 이 같은 트릭의 유사한 훨씬 오래된 예는 String . 이로 인해 UTF8이 아닌 바이트를 문자열에 넣는 것이 안전하지 않아 다른 코드에서 String 모든 데이터가 다음과 같다고 가정 할 수 있습니다. UTF8.

왜 언핀 impls를 안정적으로 만들 수 없는지에 대한 설명이 있습니까?

네거티브 impl은 현재 불안정하며 이러한 API와 전혀 관련이 없습니다.

네거티브 impls는 현재 불안정합니다.

🤦‍♂️ 말이 되네요, 조금 더 생각 했어야 했어요. 감사.

@alexcrichton 이것은이 API에 대한 훌륭한 분석입니다. 우리는 잃어 버릴 주석보다 더 잘 보존하려고 노력해야합니다!

몇 가지 의견 :

as_mut : 질문 : "악성"DerefMut impl은 어떻습니까? 이것은 안전한 방법입니다
기본적으로 & mut P :: Target을 생성하는 사용자 제공 DerefMut을 호출하려면
아마도 그것을 수정할 수 있습니다. 이게 안전 해요?

기본적으로 new_unchecked 를 호출하면이 유형에 대한 Deref 및 DerefMut 구현에 대해 약속합니다.

set : 주어진 핀

(그리고 우리가 아무것도 모른다는 사실
고정 해제), 이것이 P :: Target이 움직이지 않는다는 것을 보장하지 않습니까? 만약 우리가 할 수 있다면
그래도 다른 P :: Target으로 다시 초기화하면 안전하지 않습니까?
아니면 이것이 소멸자와 관련이 있습니까?

이것은 포인터의 이전 내용을 삭제하고 거기에 새로운 내용을 넣습니다. "고정됨"은 "삭제되지 않음"을 의미하는 것이 아니라 "삭제 될 때까지 이동하지 않음"을 의미합니다. 따라서 drop 를 호출 하는 drop 것이 중요합니다. 이것이 제가 위에서 언급 한 드롭 보장입니다.

여기서 뭔가 움직이는 게 보이나요?

map_unchecked : 질문 :: 여기서 반례는 무엇입니까? 이것이 안전하다면 Pin의 보장을 위반하는 것을 보여주는 예는 무엇입니까?

예를 들어 Pin<&&T> 로 시작하고이 메서드를 사용하여 Pin<&T> 를 가져옵니다. 고정은 참조를 "전파"하지 않습니다.

get_ref : 여기서 하나의 "아마도 문제"는 내부 가변성입니다. 만약 T가
RefCell?

실제로 이것은 문제이지만 건전성 문제는 관찰하지 않았습니다. 불건전 한 것은 Pin<RefCell<T>> 에서 Pin<&[mut] T> 로가는 메소드를 갖는 것 입니다. 기본적으로 RefCell 는 고정을 전파하지 않고 impl<T> Unpin for RefCell<T> 있습니다.

여기에 제안 된 고정 API 변형에 대해 공식적인 검증 (예 : @jhjourdan 또는 @RalfJung)이 수행 되었습니까?

아니, 우리 편이 아니야. 위에서 언급 한 블로그 게시물에는이를 공식화하는 방법에 대한 몇 가지 생각이 포함되어 있지만 실제로는이를 수행하지 않았습니다. 타임머신이나 관심있는 박사 과정 학생을 주면 우리가 할 것입니다. ;)

비동기 및 대기 / 제너레이터에 대한 지원 메커니즘으로 사용 사례를 잊어 버린 경우이를 생태계의 크레이트 안에 넣을 수 있으며 현재 제공하는 보증이 주어지면 작동할까요?

그것이 의도입니다.

고정 API를 안정화 한 결과 어떤 종류의 API 또는 유형 시스템 추가가 불가능합니까? (이 질문은 2의 확장입니다.)

어, 그 질문에 확신을 가지고 대답하는 방법을 모르겠어요. 추가 할 수있는 공간은 너무 크고 차원이 너무 커서 그것에 대해 어떤 종류의 보편적 인 진술도 할 수 없습니다.

안정화 될 API는 필드 프로젝션을 개선하기 위해 & pin T 유형을 제공하는 언어를 발전시키는 측면에서 어떤 방법을 제공합니까 (제안 된 API에서는 좋지 않은 것 같습니다).

&pin T 에 대해 더 이상 잘 모르겠습니다. 새로운 일반 Pin<T> 와 잘 일치하지 않습니다. 프로젝션 처리 측면에서 " Unpin 및 Drop 이 (가)이 유형에 대해 구현되지 않았습니다"라고 말하는 해킹이 필요합니다. 그러면 매크로를 사용하여 안전하게 수행 할 수 있습니다. 추가적인 인체 공학을 위해 우리는 언어로 된 일반 "필드 프로젝션"기능을 원할 것입니다.이 기능은 &Cell<(A, B)> 에서 &Cell<A> 로의 전환도 포함합니다.

왜 언핀 impls를 안정적으로 만들 수 없는지에 대한 설명이 있습니까?

AFAIK 네거티브 impl에는 몇 가지 오랜 제한이 있으며, 일반 경계를 추가하면 예상대로 작동하지 않는 경우가 많습니다. (일반 경계는 때때로 무시되는 경우도 있습니다.)

Chalk가이 모든 것을 고칠 수도 있고, 일부만 고칠 수도 있지만, 어느 쪽이든 Chalk에서 이것을 차단하고 싶지 않을 것입니다.

패킹은 필드를 동적으로 이동할 수 있음을 의미합니까? 그것은 약간 무섭습니다.

drop 가 정렬 된 참조를 예상하므로 패킹 된 필드에서 drop 를 호출하는 유일한 방법입니다.

llvm이 다른 상황에서 필드를 이동하는 코드를 생성하지 않을 것이라고 확신합니까? 마찬가지로 스택의 고정 된 값이 llvm에 의해 이동 될 수 있습니까?

LLVM 복사 바이트는 프로그램 동작을 변경할 수 없기 때문에 문제가되지 않습니다. 이것은 Rust에서 관찰 할 수있는 방식으로 데이터를 "이동"하는 더 높은 수준의 개념에 관한 것입니다 (예 : 데이터에 대한 포인터가 더 이상 데이터를 가리 키지 않기 때문입니다). LLVM은 포인터가있을 수있는 다른 곳으로 데이터를 이동할 수 없습니다. 마찬가지로 LLVM은 주소가있는 스택에서 값을 이동할 수 없습니다.

@RalfJung 감사합니다. 몇 가지 후속 질문 ...

"삭제 될 때까지 이동하지 않음"이라고 말하면 &mut self 가 Pin<&mut Self> 주소에서 이동 한 곳에서 &mut self Drop 가 호출 될 수 있음을 의미합니다.? 소멸자는 정확한 내부 포인터에 의존 할 수 없습니다.

set 을 (를) 볼 때 내 걱정은 패닉이 어떻게 처리되는지 였지만, 코드 젠을 조금 더 파헤쳐 보면 이것이 문제가되지 않는다고 생각합니다.

"삭제 될 때까지 이동하지 않음"이라고 말하면 &mut self 가 Pin<&mut Self> 주소에서 이동 한 곳에서 &mut self Drop 가 호출 될 수 있음을 의미합니다.? 소멸자는 정확한 내부 포인터에 의존 할 수 없습니다.

@alexcrichton 내 이해는 Drop::drop 반환 될 때까지 이동하지 않았다는 의미입니다. 그렇지 않으면 일부 사용 사례 (적어도 방해가되는 컬렉션 및 스택 할당 DMA 버퍼)가 불가능 해집니다.

소멸자는 이전에 Pin 있었음을 증명할 수 있다면 이동되지 않은 무언가에 의존 할 수 있습니다. 예를 들어 상태 머신이 고정되어야하는 API를 통해서만 상태에 들어갈 수있는 경우 소멸자는 해당 상태에있는 경우 삭제되기 전에 고정되었다고 가정 할 수 있습니다.

코드는 비 로컬 소멸자가 구성원을 이동하지 않는다고 가정 할 수 없지만 분명히 자신의 소멸자가 구성원을 작성하기 때문에 이동하지 않는다고 가정 할 수 있습니다.

"never moved until drop"이라고 말하면 & mut self가 Pin <& mut Self>의 주소에서 이동 한 곳에서 Drop이 호출 될 수 있음을 의미합니다. 소멸자는 정확한 내부 포인터에 의존 할 수 없습니다.

즉, drop 가 호출 될 때까지 데이터가 이동하지 않습니다 (할당 해제되지 않는 것을 포함하여 다른 곳으로 이동하지 않는다는 의미). 그리고 예, drop 는 유형이 그것을 표현할 수 없더라도 고정 된 위치에서 실행에 의존 할 수 있습니다. drop 은 ( 는) Pin<&mut self> (모든 유형에 대해)를 받아야 하지만 아쉽게도 너무 늦었습니다.

drop 가 호출 된 후 데이터는 의미가없는 바이트이므로 어떤 작업도 수행 할 수 있습니다. 거기에 새 항목을 넣고 할당을 취소합니다.

예를 들어 요소의 소멸자가 인접한 포인터를 조정하여 등록을 취소하는 침입 링크 목록을 허용합니다. 소멸자가 호출되지 않으면 메모리가 사라지지 않을 것입니다. (요소는 여전히 유출 될 수 있으며 그 연결 목록에 영원히 남아있을 것입니다. 그러나이 경우 유효한 메모리로 남아 있으므로 안전 문제가 없습니다.)

저는 Pin , Unpin 에서 찾을 수있는 모든 내용을 읽었으며 이에 대한 논의도 _ 생각합니다 _ 이제 무슨 일이 일어나고 있는지 이해합니다. 다른 유형의 의미와 구현 자와 사용자가 따라야하는 계약에 대한 미묘함 안타깝게도 std::pin 또는 Pin 및 Unpin 에 대한 문서에서 이에 대한 논의가 비교적 적습니다. 특히 다음 댓글의 내용 중 일부를보고 싶습니다.

• https://github.com/rust-lang/rust/issues/55766#issuecomment -436782229
• https://github.com/rust-lang/rust/issues/55766#issuecomment -437428085
• https://github.com/rust-lang/rust/issues/55766#issuecomment -437846602
• https://github.com/rust-lang/rust/issues/55766#issuecomment -437987966

문서에 통합되었습니다. 구체적으로 특별히:

• 그 Pin 는 "한 단계 깊이"만 보호합니다.
• Pin::new_unchecked 는 Deref 및 DerefMut 에 대한 impl에 제한을 둡니다.
• Pin 및 Drop 간의 상호 작용.
• !Unpin 는 Pin 배치 된 후에
• Pin<Box<T>>: Unpin where T: !Unpin 이유에 대한 근거. 이는 위의 "1 단계 깊이"제한과 다시 연결되지만 적절한 설명이 포함 된이 구체적인 예가 독자에게 도움이 될 것이라고 생각합니다.

@alexcrichton 의 반례도 꽤 유용하다는 것을 unsafe 방법에 대해 무엇이 잘못 될 수 있는지에 대한 아이디어를 제공하면 많은 도움이 될 것이라고 생각합니다 (적어도 확실히 저에게 도움이되었습니다). 일반적으로이 API의 미묘함으로 인해 다양한 안전하지 않은 메서드의 안전성 섹션이 확장되고 std::pin 모듈 수준 문서에서 참조 될 수도 있습니다.

나는 아직이 API를 많이 사용하지 않았기 때문에 지금은 좋은 상태에 있다는 기술적 판단을 믿을 것입니다. 그러나 Pin , Pinned 및 Unpin 은 매우 다른 유형 / 특성 및 비교적 복잡한 API에 대해 너무 유사하고 표현력이 없어서 이해하기가 더 어려워집니다. (이 스레드에 대한 몇 가지 의견으로 입증 됨).

그들은 마커 특성에 대한 명명 규칙을 따르는 것 같아서 실제로 불평 할 수는 없지만 장황함과 자기 설명 이름 사이의 균형을 맞출 수 있는지 궁금합니다.

• Pinned - Pin 와 같은 단어이기 때문에 다소 혼란 스럽습니다. PhantomData 와 같이 사용하면 그렇지 않으면 누락 될 메타 정보로 구조체를 보강 할 수 있습니다. PinnedData , PhantomPinned , PhantomSelfRef 또는 DisableUnpin ? 사용 패턴 및 / 또는 그로 인한 영향을 나타내는 것.
• Unpin - 등의 https://github.com/rust-lang/rust/issues/55766#issuecomment -437266922, 나는 이름으로 혼동하고있어 Unpin , 때문에 "유엔 핀 "는 여러 모호한 방식으로 이해할 수 있습니다. IgnorePin , PinNeutral 거요?

일반적으로 나는 실패하고 있지만 좋은 대체 이름을 찾는 중입니다 ...

PhantomPin과 PinNeutral은 특히 멋진 이름으로 저를 공격합니다.

대위법을 제공하기 위해 Unpin 직관적 인 것을 발견했습니다 (이해 한 후에는). Pinned 은 내 자신의 코드에서 사용하지 않았기 때문에 똑바로 유지하기가 더 어렵습니다. Pinned 를 NotUnpin 어떻습니까?

나는 더 나은 이름을 찾는 것이 더 쉽게 이야기 할 수 있도록하는 목적으로 자전거 흘리기 운동이 가치가 있다는 데 동의합니다. 내가 제안:

• Pin -> Pinned : Pin 받으면 주어진 내용이 _ 고정되었으며 _ 영원히 _ 유지 _ 될 것이라는 약속입니다. 나는 이것에 대해 너무 강하게 느끼지 않는다. 당신이 "가치의 핀"을받는 것에 대해 이야기 할 수도 있기 때문이다. Pinned<Box<T>> 은 나에게 더 좋게 읽습니다. 특히 Box 만 고정되어 있고 포함 된 내용이 아닙니다.
• Unpin -> Repin : 다른 마커 특성의 경우 일반적으로 해당 마커 특성을 가진 것으로 할 수있는 작업에 대해 이야기합니다. 이것이 아마도 Unpin 이 처음에 선택된 이유 Unpin 것을 고정한 다음 결과 나 고려없이 다른 곳에 다시 고정 할 수 있다는 것입니다. 좀 더 장황하지만 @ mark-im의 PinNeutral 제안도 마음에 듭니다.
• Pinned -> PermanentPin : Pinned 가 좋은 이름이라고 생각하지 않습니다. Pinned 가 포함 된 항목은 실제로 고정되지 않았기 때문입니다. Unpin 아닙니다 . PhantomPin 는 Pin 가 실제로 원하는 것이 아닌 Pin 참조한다는 점에서 유사한 문제가 있습니다. NotUnpin 에는 이중 부정이있어서 추론하기 어렵습니다. @Kimundi 의 PhantomSelfRef 제안은 꽤 가까워졌지만 여전히 약간 "복잡하다"고 생각하고 "한 번 고정하면 이동할 수 없음"속성을 한 인스턴스 와 연결합니다 ( 자기 참조가 있습니다). 내 제안은 PermanentlyPinned 로 표현 될 수도 있습니다. 나는 어떤 형태가 덜 나쁜지 모르겠습니다.

Pinned 은 결국 NotX 가되어야한다고 생각합니다. X 는 Unpin 가 이름이 붙는 이름입니다. Pinned 의 유일한 작업은 둘러싸는 유형이 Unpin 구현하지 않도록 만드는 것입니다. (편집 : 그리고 우리가 Unpin 를 다른 것으로 바꾸고 있다면 아마도 이중 부정은 문제가되지 않을 것입니다)

"이 유형은 다른 곳에 고정 될 수 있음"은 "이 유형은 핀에서 이동할 수 있음"의 부작용 일 뿐이므로 Repin 은 이해가되지 않습니다.

@tikue 어떤 의미에서 나는 똑같은 느낌이 들지만 반대로. Unpin 은 "this is _not_ constrained by Pin "로 표현되어야하고 Pinned 는 "this _is_ constrained by Pin "로 표현되어야한다고 생각합니다. s/Unpin/TemporaryPin , s/Pinned/PermanentPin ?

편집 : 예, Repin 가 Unpin 의 부작용 인 것에 대한 귀하의 요점을 봅니다. Pin 는 Unpin 인 유형에 대해 "중요하지 않다"는 사실을 전달하고 싶었습니다. Unpin 이 (가) 매우 잘 작동한다고 생각하지 않습니다. 따라서 위의 제안 TemporaryPin .

@jonhoo 나는 그 반대를 선호하는 주된 이유는 Pinned 이 특성이 구현되는 것을 막기 때문이라고 생각합니다. 즉, 나에게 가장 명백한 의미에서 진정한 부정적입니다.

편집 : 어떨까요?

Unpin -> Escape
Pinned -> NoEscape

흥미 롭 네요 .. 문서에 어떻게 들어가는 지 알아 보려고합니다. 다음과 같은 것 :

일반적으로 Pin<P> 받으면 P 의 대상이 삭제 될 때까지 이동하지 않는다는 보장과 함께 제공됩니다. 이에 대한 예외는 P 의 목표가 Escape 입니다. Escape 로 표시된 유형은 이동하더라도 (예 : 내부 자체 참조가 포함되지 않음) 유효하다고 약속하므로 Pin 를 "이스케이프"할 수 있습니다. Escape 는 자동 트레이 트이므로 Escape 인 유형으로 완전히 구성된 모든 유형도 Escape 입니다. 구현자는 NoEscape impl !Escape for T {} 를 사용하거나 std::phantom 의 NoEscape 마커를 포함하여 야간에이 기능을 옵트 아웃 할 수 있습니다.

"탈출"이라는 단어와의 연결이 약간 약해 보이지만 꽤 괜찮은 것 같습니다. 별도로 위의 내용을 작성하면 Pin<P> 가 P 의 대상이 이동되지 않는다는 것을 _ 정말 _ 보장하지 않는다는 것을 깨달았습니다 (정확히 Unpin 때문에). 대신, _ either_ P 의 대상이 이동하는지 _or_ P 의 대상이 이동되지 않는지 여부는 중요하지 않음을 보장합니다. 그래도 더 나은 이름 선택을 알리기 위해 그것을 사용하는 방법을 모르겠습니다 ... 그러나 그것은 아마도 문서에 어떤 식 으로든 그것을 만들어야 할 것입니다.

개인적으로 나도 이름으로 Unpin 를 싫어합니다. 아마도 impl !Unpin 로 자주 보이지만 "not-un-pin"이라고 읽고 몇 번의 두뇌 사이클이 필요하기 때문일 것입니다. '이전 모델 임)은 "좋아요. 처음 고정되면 영원히 고정 될 것입니다."라는 결론을 내릴 수 있으므로 이중 네거티브를 최적화 할 수도 없습니다.
일반적으로 인간은 긍정 대신 부정적인 생각을하는 경향이 있습니다 (직접 출처없이, 의심스러운 경우 Richard Hudson의 작업을 확인하십시오).
Btw Repin 정말 좋네요.

Pin 는 고정 된 값을 항상 고정 된 값으로 만들지 않기 때문에 설명하기 어렵습니다. Pinned 는 실제로 아무것도 고정하지 않기 때문에 혼란 스럽습니다. 그것은 단지 Pin 이스케이프를 방지합니다.

Pin<P<T>> 는 고정 된 값으로 설명 할 수 있습니다. 고정 된 값은 값이 핀을 벗어날 수있는 유형이 아니면 이동할 수 없습니다.

빠른 인터넷 검색은 레슬링에서 핀이 고정 될 때 핀에서 빠져 나가는 것을 탈출이라고 합니다.

나는 또한 Unpin 대신 이스케이프라는 용어를 좋아하지만 EscapePin 합니다.

여기에 많은 좋은 생각이 있습니다!

한 가지 일반적인 사항 : 모국어가 아닌 저에게 Pin 및 Unpin 는 대부분 동사 / 동작입니다. Pin 은 의미가 있지만 객체는 한 번에 하나의 메모리 위치에 고정되어 있으므로 Unpin 대해 동일한 위치를 볼 수 없습니다. Pin<&mut T> 참조를 받으면 Unpin 여부에 관계없이 항상 메모리 위치가 안정적이라는 의미로 T가 고정됩니다. 실제로 개체를 작업으로 고정 해제 할 수 없습니다. 차이점은 Unpin 유형은 추가 상호 작용에서 유지하기 위해 고정 보장이 필요하지 않다는 것입니다. 그것들은 자기 참조가 아니며 그들의 메모리 주소는 예를 들어 다른 객체로 보내지지 않고 거기에 저장되지 않습니다.

Unpin 실제로 의미하는 바에 대해 놀라운 작업을하는 것이 좋겠다는 @tikue의 의견에 동의하지만 정량화하기는 어렵습니다. 그러한 유형이 순전히 움직일 수 있다는 것이 아니라 순전히 자기 참조 성이 부족한 것도 아닙니다. 아마도 "객체가 이동 될 때 전체 메모리 공간의 포인터가 무효화되지 않는다"는 것입니다. 그런 다음 StableOnMoveAfterPin 또는 StableMove 것이 옵션이 될 수 있지만 그 또한 좋지 않은 것 같습니다.

나를 위해 Repin 는 Unpin 와 동일한 합병증을 가지고 있습니다. 즉, 한 가지가 먼저 고정 해제된다는 것을 의미합니다. 내 이해로는 발생하지 않습니다.

특성은 대부분 유형의 Pin 를 본 후 발생하는 일을 정의하기 때문에 PinNeutral 또는 PinInvariant 것이 나쁘지 않습니다.

Pin vs Pinned 와 관련하여, 나는 그것을 보는 시점의 포인터 상태이기 때문에 Pinned 선호한다고 생각합니다.

@ Matthias247 P: Unpin 경우 P::Target 의 주소가 안정적이라는 보장이 없다고 생각합니다. 나는 이것에 대해 틀릴 수 있습니까?

안녕하세요.

Pin <& mut T>에 대한 참조를 받으면 고정 해제 여부에 관계없이 항상 메모리 위치가 안정적이라는 의미로 T가 고정됩니다.

이것의 의미를 명확히 할 수 있습니까? T: Unpin 주어지면 다음을 작성할 수 있습니다.

let pin_t: Pin<&mut T> = ...
let mut other_t: T = ...
mem::replace(Pin::get_mut(pin_t), &mut other_t);
// Now the value originally behind pin_t is in other_t

@jonhoo 실제로 좋은 질문입니다. 내 추론은 선물이 상자에 들어간 다음 poll() 메서드가 동일한 메모리 주소에서 호출된다는 것입니다. 그러나 이것은 분명히 최상위 수준의 작업 / 미래에만 적용되며 중간 계층은 Unpin 때 선물을 이동할 수 있습니다. 그래서 당신이 옳은 것 같습니다.

최신 자전거 흘리기 :

• Unpin : MoveFromPin 어떻습니까? 여전히 약간의 미묘함을 놓치고 있지 않다면 이것이 특성이 실제로 활성화하는 기능을 직접적으로 설명한다고 생각합니다. 유형이 Pin 내에 있으면 여전히 이동할 수 있습니다.

  결정적으로 그것은 Unpin 과 같은 것을 말합니다. 그러나 긍정적 인 주장으로 틀을 잡았습니다. 그래서 이중 부정 !Unpin 대신에 !MoveFromPin 있습니다. 나는 그것이 해석하기 더 쉽다고 생각한다. 적어도 ... 그것은 어, 당신이 핀에서 옮길 수없는 타입들이다.

  (기본 아이디어에는 약간의 변형 여지가 있습니다 : MoveOutOfPin , MoveFromPinned , MoveWhenPinned 등)

• Pinned : 그러면 NoMoveFromPin 가 될 수 있으며 그 효과는 !MoveFromPin 유형을 만드는 것입니다. 충분히 간단 해 보인다고 생각합니다.

• Pin 자체 : 이것은 다른 두 개와 연결되어 있지 않고 그다지 중요하지 않지만 여기에서도 약간의 개선의 여지가 있다고 생각합니다.

  문제는 Pin<&mut T> (예를 들어)가 &mut 가 고정되었음을 의미하는 것이 아니라 T 가 (내가 본 것 같은 혼란 적어도 하나의 최근 의견 증거). Pin 부분은 &mut 에 대한 일종의 수정 자 역할을하므로 Pinning 라고 부르는 것이 더 나은 경우가 있다고 생각합니다.

  이 몇 가지 간접적 인 선례가있다 : 우리가 대신 공포의 주위에 래핑하는 정수형의 오버 플로우 의미를 수정하려면, 우리는 말할 Wrapping<i32> 보다는 Wrap<i32> .

이것들은 모두 원본보다 길지만, 이것에 대한 추론이 얼마나 섬세한지를 고려할 때 더 명확성을 위해 가치있는 투자가 될 수 있습니다.

Re : Repin , 다음과 같을 것으로 예상합니다.

unsafe trait Repin {
    unsafe fn repin(from: *mut Self, to: *mut Self);
}

가끔 콘텐츠를 이동하는 Vec -like 컬렉션 내에서 !Unpin 유형을 지원하는 데 사용할 수 있습니다 (이는 이러한 특성을 추가하기위한 제안이 아닙니다. 특성 이름).

또한 이름을 bikshedding :

• Pin<P> -> Pinned<P> : 포인터 P 가리키는 값이 메모리에 고정됩니다 (삭제 될 때까지).
• Unpin -> Moveable : 값을 고정 할 필요가 없으며 자유롭게 이동할 수 있습니다.
• Pinned (struct)-> Unmoveable : Pinned 이어야하며 이동할 수 없습니다.

나는 Pin 또는 Unpin 가 변경되어야한다고 생각하지 않으며, 대안은 모두 내 의견에 명확하지 않고 자세한 내용을 추가하거나 오해의 소지가 있습니다. 또한 우리는 이미이 대화를했고 Pin 및 Unpin 를 사용하기로 결정했으며이 스레드에서 가져온 인수 중 어떤 것도 새로운 것이 아닙니다.

그러나 Pinned 는 이전 논의 이후 추가되었으며 PhantomData 와 같은 팬텀 마커 유형을 지우려면 PhantomPinned 를 만드는 것이 합리적이라고 생각합니다.

개인적으로 나도 Unpin을 이름으로 사용하는 것을 매우 싫어합니다. 아마도 그것이 "not-un-pin"이라고 읽고 결론을 내리기 위해 몇 번의 두뇌 사이클을 필요로하는 impl! "좋아요. 이건 처음 고정되면 영원히 고정 될 것입니다."라는 뜻입니다. 그래서 이중 부정을 최적화 할 수도 없습니다.

이것은 내 경험과 완전히 반대입니다. !Unpin 수동으로 구현한다는 것은 매우 틈새 시장 인 안전하지 않은 코드를 사용하여 수동으로 자체 참조 구조를 구현한다는 것을 의미합니다. 반대로, 포인터 뒤에 잠재적으로 고정 해제 된 구조체를 유지하는 모든 것은 Unpin 의 양의 impl을 갖습니다. 예를 들어 std 에서 Unpin 의 모든 impls는 양의 극성입니다.

@withoutboats 여기에 제기 된 논쟁이 이미 논의 된이 이름들에 대한 이전 논의에 대한 링크를 제공 할 수 있습니까?

RFC 스레드 및 추적 문제 https://internals.rust-lang.org/t/naming-pin-anchor-move/6864 에서도 확실히 논의되었지만 다음은 스레드 하나입니다.

(이 스레드의 앵커 및 핀 유형은 이제 Pin<Box<T>> 및 Pin<&'a mut T> )

Unpin은 Unpinnable의 약자로 읽혀야합니까? 핀 내부에 있더라도 실제로 고정 된 값을 유지할 수 없기 때문에 고정 할 수 없습니다. (그게 내 부분에 대한 올바른 이해입니까?)

일부 문서 및 댓글 스레드를 살펴 보았지만 Unpinnable에 대한 참조는 특별히 보지 못했습니다.

고정 해제는 무엇이든 줄여서는 안됩니다. 내가 생각하는 한 가지는 많은 사용자에게 분명하지 않지만 사실입니다. 표준 라이브러리 스타일 가이드는 형용사가 아닌 특성 이름으로 동사를 선호한다는 것입니다. 따라서 Sendable 아니라 Send Sendable . 이것은 완벽한 일관성으로 적용되지 않았지만 표준입니다. Unpin 는 고정한 Pin 에서이 유형을 고정 해제 할 수 있으므로 "고정 해제"와 같습니다.

같은 이름 Move ( "이동"하지 기억)를보다 명확 Unpin 그들이 오히려에 동작을 연결하는 것보다, 전혀 이동할 수있는과 관련이 있다는 것을 의미하기 때문에 핀 유형. Rust에서 Sized 값을 이동할 수 있기 때문에 !Unpin 유형을 이동할 수 있습니다.

내가 본 것처럼 전체 문구 인 이름은 std에 대해 매우 단관적일 것입니다.

짧지 않을 수도 있지만 정확히 내가 읽는 방법입니다. 특성은 동사이기 때문에 유형에 대한 연산이 아닌 유형을 설명하는 데 사용하려면 수동으로 형용사로 변환해야합니다. std::iter::Iterator 는 반복 가능한 무언가에 의해 구현되고, std::io::Seek 는 검색 가능한 무언가에 의해 구현되고, std::pin::Unpin 는 고정 불가능한 무언가에 의해 구현됩니다.

@withoutboats 동사 문제가없는 다른 이름의 특정 문제, 예를 들어 Escape 또는 EscapePin ? 이 토론이 이전에 일어났다는 것을 이해했지만 지금은 더 많은 시선이 집중되어 있으므로 완전히 중복 된 재해시인지 확실하지 않습니다.

나는 사실 생각 한가지는 자사의 불운이 Pin 및 Unpin (어떤 종류의 "핀"이며, 일부는 "고정 해제"이다) 한 쌍으로 읽을 수, 경우 Pin 는 동사가 아닌 명사 여야합니다. Pin 이 특성이 아니라는 사실이 상황을 명확히 해줍니다. Pinning 에 찬성하는 주장은 타당하지만 여기서는 이름 길이 문제에 맞서게됩니다. 방법 수신기를 반복해야합니다 특히 때문에 self : 두 번, 우리는 문자의 많은 끝낼 self: Pinning<&mut Self> . Pinning<P> 이 Pin<P> 보다 명확 할 가치가있는 전체 4 자라는 것을 확신하지 못합니다.

@tikue "탈출"용어는 내가 생각하는 고정보다 훨씬 더 과부하되어 탈출 분석과 같은 개념과 충돌합니다.

또한 우리는 이미이 대화를했고, Pin과 Unpin을 사용하기로 결정했고,이 스레드에서 제기 된 어떤 주장도 새로운 것이 아닙니다.

이것은 저를 잘못된 방식으로 문지릅니다. 커뮤니티의 경험 보고서가 원하지 않습니까? 개인적으로이 스레드의 다른 댓글과 Pinned 이중 네거티브와의 병치에서 Unpin 대한 명확한 문제를 보지 못했습니다.

Rust는 이스케이프 분석을 수행하지 않으므로 이것이 실제 문제라고 생각하지 않습니다.

: bell : 지금은 위 의 에 따라 최종 댓글 기간을 입력합니다 . :벨:

이 땅에 도달하기 전에 https://github.com/rust-lang/rust/issues/55766#issuecomment-438316891에 설명 된대로 문서 개선 사항을보고 싶습니다. :)

https://github.com/rust-lang/rust/pull/55992 를 열어 위에 제안 된 문서를 추가하고 Pinned 을 PhantomPinned .

Pinned (및 PhantomPinned )는 "고정 된"값을 Pin 밖으로 이동할 수없는 것으로 개념화하도록 장려합니다. 즉, Pin 에있는 많은 값을 의미합니다. Unpin )는 "고정" 되지 않습니다 !

혼란스러워 보입니다. Pin 모든 값이 Pin 에있는 동안 고정 된 것으로 개념화하는 것이 더 쉬우 며 고정되는지 여부는 이전에 Pinned 이라는 이름이 영구적 인지 여부입니다 Pinned 컨트롤. Pin* 와 다른 이름은 두 개의 다른 개념이 혼동되는 것을 방지합니다.

PhantomNotUnpin : P

개인적으로 나도 Unpin을 이름으로 사용하는 것을 싫어합니다. 아마도 impl! Unpin이 "not-un-pin"이라고 읽고 여러 뇌주기를 필요로하기 때문일 것입니다.

감사! 나는 또한 꽤 오랫동안 Unpin 에 의해 귀찮게 봇이 그 이유를 정확히 지적 할 수 없었습니다. 이제 나는 이해한다고 생각합니다. 그것은 이중 부정입니다.

이것은 내 경험과 완전히 반대입니다. 수동으로! Unpin을 구현한다는 것은 매우 틈새 시장 인 사용 사례 인 안전하지 않은 코드를 사용하여 수동으로 자체 참조 구조를 구현한다는 것을 의미합니다. 반대로, 포인터 뒤에 잠재적으로 고정 해제 된 구조체를 유지하는 모든 것은 Unpin의 양의 impl을 갖습니다. 예를 들어 표준에서 Unpin의 모든 impls는 양의 극성입니다.

그러나 구현뿐만 아니라 토론에 관한 것입니다. impl !Sync 은 매우 드물지만 (불안정하기 때문에 혼자가 아닙니다) Sync 및 !Sync 유형에 대해 이야기하는 것은 매우 일반적입니다. 비슷하게, !Unpin 는이 기능에 대한 논의에서 상당히 많이 나왔는데, 적어도 제가 가지고 있었던 것입니다.

저도 속성을 긍정적으로 표현하는 것을 선호합니다 ( MoveFromPin 정도). 나는 인간 공학에 완전히 확신하지 못합니다. Pin 와는 달리이 특성 경계를 자주 쓸 필요가 없기 때문입니다.

Rust는 이스케이프 분석을 수행하지 않으므로 이것이 실제 문제라고 생각하지 않습니다.

LLVM은 그렇기 때문에 이스케이프 분석은 여전히 ​​Rust와 관련이 있습니다.

이를 해결하는 방법은 Pin / Unpin 의 의미를 뒤집는 단어를 선택하는 것입니다. 예를 들면, 이름을 변경 Unpin 에 Relocate . 그러면 !Unpin 는 !Relocate 됩니다. 그것은 나에게 훨씬 더 직관적 인 의미가 있습니다. "오,이 유형의 개체는 재배치 할 수 없습니다"라고 읽었습니다. 또 다른 경쟁자는 Movable 입니다.

Pin 대체 할 수있는 반대 단어가 무엇인지, 아니면 필요한지 모르겠습니다. 그러나 나는 문서가 다음과 같이 말하는 것을 확실히 상상할 수 있습니다.

고정 된 개체는 개체를 메모리에 재배치 할 수있는 경우에만 DerefMut 를 통해 직접 수정할 수 있습니다. Relocate 는 자동 트레이 트이며 기본적으로 추가됩니다. 그러나 값을 보유하는 메모리에 대한 직접 포인터가있는 경우 유형에 impl !Relocate 를 추가하여 Relocate 에서 옵트 아웃합니다.

impl<T: Relocate> DerefMut for Pin<T> { ... }

이것은 Unpin 보다 훨씬 더 직관적입니다.

위에서 제안한 문서를 추가하기 위해 # 55992를 열었습니다.

이것은 https://github.com/rust-lang/rust/issues/55766#issuecomment -438316891에서 제안 된 것의 일부만 추가합니다.

MoveFromPin 제안이 마음에 듭니다. Relocate 도 좋지만 Pin 와 (과) 관련이 충분하지 않을 수 있습니다. 이동 불가능한 유형으로 다시 이해할 수 있습니다. RelocateFromPin 가 다시 좋을 것입니다.

Escape ing은 예를 들어 Swift에서 클로저와 관련이 있으며 현재 콜 체인 내부 또는 외부에서 호출되는지 여부입니다. 오해의 소지가있는 것 같습니다.

명확성을 돕는 한 긴 이름의 문제는 보이지 않습니다.

FWIW 투표를 통해 Unpin 이름을 Relocate 또는 MoveFromPin 와 같은 "긍정적 인"이름으로 바꾸고 싶습니다 (또는 더 장황하지만 약간 더 정확한 MayMoveFromPin ).

!Unpin 또는 Unpin 의 이중 부정이 역사적으로 저에게 혼란 스러웠고 긍정적 인 "이것은 Pin 안에 있음에도 불구하고 움직일 수 있습니다"라는 점에 동의합니다. 혼란을 덜어 줄 것입니다!

FWIW 처음에는 Unpin 에 대해 똑같은 생각을했지만 실제로 IMO를 사용하려고했을 때 의미가있었습니다. 찾고있는 작업이 Unpin 기능이기 때문에 실제로 이중 부정이 아닙니다 Pin 자유롭게 들어오고 나가기)는 물건을 고정하는 능력이 아닙니다. MoveFromPin 와 동일하며 다른 단어로만 표시됩니다. 나는 사람들이 " Pin "같은 것이 아니라고 생각하게 만들지 않는 이름을 선호하지만 IMO MoveFromPin 와 다른 사람들은 너무 말이 많다. UndoPin ? (haskell 군중을 위해 FreePin ?)

나는 아직도 !Unpin 이상하다고 생각한다 – 나는 내면의 목소리를 "이걸 풀지 마!"처럼 취급하도록 훈련시켰다. 일반적인 " Unpin 구현하지 않음"대신 약간의 노력이 필요합니다.

!Pluck 어떻습니까?

@runiq

일반적인 "고정 해제를 구현하지 않음"대신

이전 의견에서 이것을 언급했지만 실제로는 이것이 좋은 표현이라고 생각합니다. Unpin 은 Pin<C<_>> 를) 들어오고 나가는 작업입니다. Unpin 구현하지 않는 것은 그러한 기능을 제공하지 않습니다.

@cramertj 저는 UndoPin 아주 좋아합니다

@cramertj 나는 지금까지 제안 된 대안의 열렬한 팬이 아니라는 데 동의하지만, 개인적으로 MoveFromPin 보다 Unpin MoveFromPin 라는 단어를 선호합니다. 이중 부정이 아니라는 것이 좋은 점이지만 (아직 일하지 않은 사람으로서) 그것을 읽으면 이중 부정이라는 사실이 계속해서 나를 괴롭 힙니다. "Un"접두사를 음수로 계속 읽으려고합니다 ...

호기심이 많지만 @cramertj 또는 다른 사람들은 Unpin 바인딩이 인체 공학적으로 얼마나 많이 나오는지에 대한 좋은 핸들이 있다고 생각합니까? 매우 희귀합니까? 매우 흔한가요? 타이핑하는 것이 고통 스럽다면 고통 스러울 정도로 흔한가요?

짧고 달콤한 이름의 경우 개인적으로 Relocate 아이디어가 마음에 들지만, 더 길고 단어가 더 많은 아이디어의 경우에는 MoveFromPin 좋아합니다. Unpin 보다 낫다고 느낍니다.

호기심이 많지만 @cramertj 또는 다른 사람들은 나오는지에 대한 좋은 핸들이 있다고 생각합니까? 매우 희귀합니까? 매우 흔한가요? 타이핑하는 것이 고통 스럽다면 고통 스러울 정도로 흔한가요?

내 경험상 Unpin 실제로 사용자 코드에 나타나는 두 가지 경우가 있습니다.

1. 폴링 할 때 실제로 미래를 움직여야하기 때문에 Unpin 경계 가 나타납니다 (예 : 일부 API 선택).
2. 더 일반적으로, 미래가 미래가 아닌 다른 것에 대해서만 일반적인 경우 일반적으로 Unpin 의 무조건 구현 을 추가하려고합니다. 다른 유형이 Unpin 인지 여부는 중요하지 않기 때문입니다. 그들에게 프로젝트를 고정하십시오.

두 번째 경우의 예는 일반적인 버퍼 유형 (예 : T: AsRef<[u8]> )이있는 경우입니다. 슬라이스를 꺼내기 위해 고정 할 필요가 없으므로 Unpin 구현 여부는 신경 쓰지 않으므로 유형이 무조건 Unpin 구현한다고 말하면 구현할 수 있습니다. Future 고정 무시.

Unpin 는 경계로 보는 것이 매우 일반적입니다. select! , StreamExt::next 및 기타 결합자는 모두 작동하는 유형이 Unpin 이어야합니다.

@withoutboats 나는 당신의 요점 2에 대해 궁금합니다. impl Unpin 가 사람들이 자주 구현하는 것을 기억해야 할 것이라고 생각합니까? 오늘날 라이브러리 작성자가 사용자 지정 형식에 대해 #[derive(Debug)] 또는 impl std::error::Error 를 잊어 버리는 것과 비슷하여 이러한 라이브러리를 사용하기가 더 어렵습니까?

고정 해제는 자동 특성입니다. 고정 해제를 구현하지 않는 유형을 갖게되는 유일한 경우는 해당 유형이 명시 적으로 옵트 아웃하는 경우입니다. (또는 고정 해제를 해제하는 필드가 포함되어 있습니다).

나는 그것이 사실임을 이해합니다. 그리고 저는 그것이 가장 일반적인 경우라고 생각했습니다. 그래서 @withoutboats 가 두 번째 요점을 언급 한 것에 놀랐습니다. 그것은 내가 원래 생각했던 것보다 더 흔할 수 있다는 것을 암시합니다 (아마도 자신의 미래를 구현할 때만). 그래서 나는 그런 종류의 사용 사례의 빈도에 대해 궁금합니다 :)

@alexcrichton 호기심이 많지만 @cramertj 또는 다른 사람들은 나오는지에 대한 좋은 핸들이 있다고 생각합니까? 매우 희귀합니까? 매우 흔한가요? 타이핑하는 것이 고통 스럽다면 고통 스러울 정도로 흔한가요?

내 코드를 Futures 0.3 ( Pin )으로 이식 한 경험에 대한 긴 게시물 을 작성

Unpin 는 거의 모든 유형에 대해 자동 구현되기 때문에 대부분의 경우 Unpin 에 대해 전혀 걱정할 필요가 없습니다.

따라서 Unpin 에 대해 걱정해야 할 유일한 시간은 다음과 같습니다.

1. 다른 유형 (예 : struct Foo<A> )보다 일반적인 유형이 있습니다.

2. 그리고 해당 유형에 대해 고정 API (예 : Future / Stream / Signal )를 구현하려고합니다.

이 경우 다음을 사용해야합니다.

impl<A> Unpin for Foo<A> where A: Unpin {}

아니면 이거:

impl<A> Unpin for Foo<A> {}

impl<A> Future for Foo<A> where A: Unpin { ... }

일반적으로 Unpin 가 필요한 유일한 상황입니다. 보시다시피 일반적으로 유형 당 Unpin ~ 2 번 사용해야합니다.

비결 합자의 경우 또는 Future / Stream / Signal 구현하지 않는 유형의 경우 Unpin 를 사용할 필요가 없습니다. 전혀

그래서 저는 Unpin 가 아주 드물게 나오고, Future / Stream / Signal combinator를 만드는 상황에서만 나타납니다.

그래서 저는 MoveFromPin 와 같은 이름을 강력히 선호합니다. 고정은 대부분의 사람들이 다룰 필요가없는 틈새 기능이므로 이름 길이를 과도하게 최적화해서는 안됩니다.

드문 상황에서 몇 명의 문자를 저장하는 것보다인지 적 이점 (이중 부정을 피하는 것)이 훨씬 더 중요하다고 생각합니다.

특히 고정은 이미 이해하기에 충분히 어렵 기 때문입니다! 그러니 불필요하게 어렵게 만들지 말자.

@jonhoo 우리는 impl Unpin 가 사람들이 자주 구현하는 것을 기억해야 할 것이라고 생각합니까? 오늘날 라이브러리 작성자가 사용자 지정 형식에 대해 #[derive(Debug)] 또는 impl std::error::Error 를 잊어 버리는 것과 비슷하여 이러한 라이브러리를 사용하기가 더 어렵습니까?

impl Unpin 를 잊을 수 없다고 생각합니다. 왜냐하면 작성자가 잊어 버리면 컴파일러 오류가 발생하여 상자가 처음에 게시되는 것을 방지하기 때문입니다. 따라서 #[derive(Debug)] 와는 전혀 다릅니다.

@withoutboats 가 말하는 상황은 Future / Stream / Signal combinator를 구현하는 사람들에게만 해당되며 다른 사람에게 영향을주지 않습니다 (특히, 도서관의 다운 스트림 사용자).

(나는 이중 부정이 그것의 일부라고 생각하고, 아마도 엄격히 필요한 것보다 더 부정적 일 수도 있지만, 이것이 전체 이야기가 아니라고 생각합니다 (여기서 성찰하려고합니다) ... "고정 해제"는 약간 , 은유 적입니까? 간접적입니까? 설명 할 때 이해가되며 "고정"자체가 이미 은유이기 때문에 내 뇌가 그 은유를 추가하는 데 문제가있는 이유는 분명하지 않지만 그럼에도 불구하고 내 뇌는의 의미를 찾습니다. 어떤 이유로 "고정 해제"는 모호하고 단단히 고정하기 어렵습니다.)

나는 당신이 옳다고 생각합니다 @cramertj , 그것은 일반적인 의미에서 실제로 이중 부정이 아니지만 @alexcrichton 및 @glaebhoerl 처럼 계속해서 넘어지고 있습니다. 접두사로 "되지 않는다는 것은"는 그것에 매우 부정-Y 느낌 ( "안전하지 않은", "구현되지 않은"등 나는 보통 해당 접두어가 발생하는 방법입니다)을 가지고 있으며, 그것은 단지 동사 같은 경우, 여기에 고정 부정된다.

@withoutboats 나는 당신의 요점 2에 대해 궁금합니다. impl Unpin이 사람들이 자주 구현하는 것을 기억해야 할 것이라고 생각합니까? 오늘날 라이브러리 작성자가 사용자 지정 형식에 대해 # [derive (Debug)] 또는 impl std :: error :: Error를 자주 잊어 버리는 것과 비슷하여 이러한 라이브러리를 사용하기가 더 어렵습니까?

절대적으로하지! 사용자가 미래가 아닌 일반적인 Future 를 수동으로 구현하는 경우 안전하지 않은 코드를 작성하지 않고 향후 구현에서 상태를 변경할 수 있기를 원할 것입니다. 즉, Pin<&mut Self> 를 &mut self 합니다. MyFuture<T: AsRef<[u8]>> 이 Unpin 구현하지 않는다는 오류가 표시됩니다. 이 문제에 대한 최선의 해결책은 Unpin 구현하는 것입니다. 그러나 이것이 미치는 유일한 영향은 Future 구현하려는 사용자에게 있으며 코드가 컴파일되지 않기 때문에 잊어 버리는 것은 불가능합니다.

@withoutboats 가 말하는 상황은 Future / Stream / Signal combinator를 구현하는 사람들에게만 해당되며 다른 누구에게도 영향을 미치지 않습니다 (특히 라이브러리의 다운 스트림 사용자에게는 영향을 미치지 않음).

나는 구체적으로 비 결합 제네릭 수동 선물 에 대해 이야기하고 있는데, 제네릭이 Unpin 가 아니더라도 Unpin 의 총괄 impls 만 있어야합니다.

"수동 미래 / 스트림을 구현할 때 고정에 대해 어떻게해야합니까?"라는 질문에 대한 순서도를 만들었습니다.

조금 더 자전거 타기를 위해 오늘 점심 시간에 LeavePin 생각해 냈습니다. 묵시적인 오해의 소지가없는 escape 와 동일한 톤을 전달합니다.

수명과 마찬가지로 impl 전문가 와 핀 사이에 흥미로운 상호 작용이 있습니까?

하위 문자열 "specializ"는 문제 토론 을

@vi 는 건전성 상호 작용이 없을뿐만 아니라 건전성 상호 작용도 가능 하지 않습니다. 핀 API는 표준 라이브러리에서 엄격하게 정의되며 새로운 언어 기능을 포함하지 않습니다. 사용자는 타사 라이브러리 에서처럼 쉽게 정의 할 수 있습니다. 이 라이브러리 코드가 존재하는 상황에서 언어 기능이 건전하지 않으면 모든 사용자가 오늘이 라이브러리 코드를 작성할 수 있고 제대로 컴파일 될 것이기 때문에 건전하지 않은 기간 입니다.

이 라이브러리 코드가 존재하는 상황에서 언어 기능이 건전하지 않으면 모든 사용자가 오늘이 라이브러리 코드를 작성할 수 있고 제대로 컴파일 될 것이기 때문에 건전하지 않은 기간입니다.

그것이 pin 에 어떤 영향을 주어야한다는 것은 아니지만, 그렇게 간단하지 않다고 생각합니다.

라이브러리 기능이 unsafe 를 사용할 때 동작이 아직 지정되지 않은 언어 구조를 사용하는 경우 (예 : &packed.field as *const _ , 또는 ABI에 대한 다양한 가정을 수행) 추가 언어 변경이 가정을 무효화하는 경우 그 라이브러리의 언어 변경이 아닌 건전하지 않은

MoveFromPin 또는 유사 항목에 +1

"언제 내 유형에 대해 Unpin 구현을 해제해야합니까?"라는 질문을하는 경우 대신 "내 유형에 대해 MoveFromPin을 언제 구현 취소해야합니까?"라고 묻는다면 대답이 훨씬 더 명확 해집니다.

"여기에 결합 된 특성으로 고정 해제를 추가해야합니까?"와 동일합니다. vs "여기서 MoveFromPin을 트레이 트 바운드로 추가해야합니까?"

고정은 아닙니다!

이것이 어딘가에서 언급 되었다면 미안하지만 여기 Pin, 구현 문제 및 RFC 문제에 관한 방대한 양의 논의 만 훑어 보았습니다.

녹이 생길 것입니다! 나는 확실히 그런 일에 대한 사용 사례를 볼 수 있습니다. (좋아, 나는 움직일 수없는 유형으로 발에 총을 쏘지 않는 방법을 찾고 있었기 때문에 Pin에 대해 찾았습니다.) 대답이 '예'라면 Pin과 어떻게 상호 작용할까요? Pin의 존재가 이미! Move를 추가하는 것보다 더 어렵게 만들까요?

위 의 병합 처리가 포함 된 최종 댓글 기간이 이제 완료되었습니다 .

고정 해제의 이름 지정에 대해 해결되지 않은 문제가 있어야합니다.

@RalfJung이 지적했듯이 # 55992는 https://github.com/rust-lang/rust/issues/55766#issuecomment -438316891 및 다른 곳에서 요청한 추가 문서의 소량 만 추가합니다. 그것이 아직 합병하지 않는 근거라는 것을 모릅니다.

내 drop () 메서드가 이제 Pin 대신 & mut self를 다시받는 이유는 무엇입니까?

음, drop ()은 오래되었습니다. Rust 1.0 이후로 존재하므로 변경할 수 없습니다. 우리는 Pin <& mut Self>를 사용하도록 만들고 싶습니다. 그러면 Unpin 유형이 지금처럼 & mut을 얻을 수 있지만 이는 이전 버전과 호환되지 않는 변경입니다.

이 변경 사항을 이전 버전과 호환되는 방식으로 구현할 수 있는지 궁금합니다. Unpin 추가 할 때까지 AIUI (그리고 사람들은 !Unpin 지정할 수 있음) 모든 유형이 Unpin 구현합니다. 그래서 우리는 특성을 추가 할 수 있습니다.

trait DropPinned {
    fn drop(Pin<&mut> self);
}

그리고 모든 Unpin 유형에 대해이 특성을 단순화합니다. 사람들이 옵트 아웃 할 수있을 때까지 모든 유형이 있습니다. 다음과 같은 것 :

impl<T> PinDrop for T where T:Unpin + Drop {
    fn drop(Pin<&mut T> self) {
        Drop::drop(self.get_mut());
    }
}

그럼 우리는 호출을 삽입 컴파일러 거라고 DropPinned::drop 대신 Drop::drop . 본질적 특징 부 (trait) DropPinned 아닌 LANG 항목이된다 Drop . AFAICS 이것은이 메커니즘이 Unpin 와 동시에 도입 된 경우에만 이전 버전과 호환됩니다.

고정 해제의 이름 지정에 대해 해결되지 않은 문제가 있어야합니다.

@tikue libs 팀원은 FCP 이전 또는 도중에 rfcbot에 우려를 제기하지 않았으며 Unpin 에 대한 주장이이 스레드에 새롭거나 새롭다 고 생각하지 않으므로 일반적으로 프로세스는 현재를 고려합니다. 마무리 할 이름입니다. 누군가 우려 사항이있는 경우 신고해야하지만 팀 체크 박스 뒤에 FCP가있는 요점은 모든 사람이 제안 된대로 API를 편안하게 안정화 할 수 있도록하는 것입니다.

@cramertj 조금 혼란 스러워요. 여러 사람 이 말을했습니다. Unpin 의 이름에 대한 논쟁이 제기되고 해결 된 다른 곳에 대한 참조를 요청했을 때 https://internals.rust-lang.org/t/naming-pin-anchor-를 가리 켰습니다. 또한 볼 수의 이름에 대해 불평하는 사람들이있다, Unpin , 그리고 진짜 반론. https://github.com/rust-lang/rfcs/pull/2349 의 원래 RFC는 Unpin 대해 제안 된 대안이 왜 더 나쁜지에 대한 근거가별로 없습니다. 이 스레드에서도 실제로 등장하는 유일한 반론은 "짧다"와 "기술적으로 정확하다"입니다. 이해하기 쉬운 대체 이름 (예 : MoveFromPin )이 논의되고 거부되는 구체적인 논의를 지적 할 수 있습니까?

나는 이전 의견에서 왜이 글에서 새로운 관점이 제기되었다고 믿는지 설명했습니다. 나는 처음부터 pin API 토론을 상당히 면밀히 따르고 있으며이 스레드 이전에 이중 부정 문제가 제기 된 것을 본 적이 없었습니다.

@tikue 나는 이중 음성 문제를 여러 번 제기하고 보았고 Unpin 의 정확한 이름이 여러 번 문제로 제기되었으며 Unpin 에 찬성하여 지속적으로 해결되었습니다. Unpin 의 이름이 포함되지 않은 위의 안정화 제안에 서명했습니다. 해결되지 않은 질문으로 Unpin : 대안에 대해 논의했으며이 FCP는 Unpin 라는 이름을 포함하여 내려진 결정을 안정화 할 준비가되었는지 결정하는 프로세스

@cramertj 토론이 발생한 위치에 대한 링크를 제공해 주시겠습니까? 나는 당신을 의심하지 않습니다. Unpin 찬성하는 주장을보고 싶습니다. 왜냐하면 나는 그들이 여기에 주어 졌다고 믿지 않기 때문입니다. 언급했듯이 지금까지 제공된 참조는 Unpin 이름 지정에 대한 해결책을 제공하지 않습니다.

@cramertj +1 @jonhoo 의 질문에. 공식 채널에 등록되지 않은 libs 팀 간의 토론이 있다면, 그 토론의 주된 요지는 여기서 반복되어야한다고 생각합니다. RFC 결정은 공개적으로 알려진 주장에 의해서만 내려 질 수 있다는 공식적인 규칙조차 있다고 생각합니다.

RFC 결정은 공개적으로 알려진 주장에 의해서만 내려 질 수 있다는 공식적인 규칙조차 있다고 생각합니다.

네, 그건 사실입니다. 그리고 기록상 저는 libs 팀에 속해 있지 않으므로 libs 팀 전용 토론에 참석 한 적이 없습니다. RFC 스레드와 Pin 추적 문제를 살펴보면 Unpin 라는 이름이 나오는 경우가 많이있었습니다. 나는 누군가가 특별히 단어 "더블 네거티브 (Double Negative) '라고 표시되지 않습니다,하지만 확실히"기억 !Unpin 무엇을 당신이 할 수있는 이름 지정 특성의 일반적인 API 규칙뿐만 아니라, 이전에 제기 된 이중 부정이다 " 오히려 내가 위에서 지적한대로 (내가 생각할 수있는 것보다, 그들과 함께 할 수 Unpin 그것을 실현하는 형용사로 듣는 것보다 동사 오히려으로 "고정 해제"를 듣고 필요하지만, 실제로이 두 가지 규칙을 따른다 사람들에게 직관적이지 않은 "고정이 아님").

@wmanley 즉, 예를 들어, 작동하지 않는 impl<T> Drop for Vec<T> 우리가이 없기 때문에 휴식 것이 Vec<T>: Unpin . 또한이 줄에 따른 제안은 이전 에이 스레드 에서도 이루어졌습니다. 회신하기 전에 토론 내용을 읽으십시오. 나는 그것이 상당히 많은 것을 요구한다는 것을 알고 있지만, 동일한 문제가 반복해서 설명되는 것을 피할 수있는 유일한 방법입니다.

RFC 결정은 공개적으로 알려진 주장에 의해서만 내려 질 수 있다는 공식적인 규칙조차 있다고 생각합니다.

이것은 비공식적으로 "새로운 근거 없음"규칙 으로 알려져 있습니다.

이 글을 어디에 게시 해야할지 모르겠지만 누군가 https://github.com/rust-lang/rust/issues/56256을 볼 수 있습니까?

# 56256과 관련하여 impl<T> From<Box<T>> for Pin<Box<T>> 는 OP에 안정화 된 것으로 나열되지 않지만 Pin 가 처리되면 암시 적으로 안정화됩니다. 사소하지 않고 안정화를 위해 검토해야하는 다른 특성 구현이 있습니까? (문서를 스캔하면 다른 모든 것은 나에게 래핑 된 포인터에 대한 사소한 위임 구현으로 보입니다).

오늘 libs 팀에서이 문제에 대해 이야기했습니다. 지난 몇 주 동안 논의 된 바에 따르면, 특히 Unpin 의 이름과 관련하여 먼저 해결해야 할 몇 가지 사항이 있습니다.

따라서 지금은이를 안정화하는 작업을 진행하지 않을 것입니다 (FCP에도 불구하고).

누군가이 스레드에서 아이디어를 모으고 명명 상황을 개선하기위한 독립형 제안을 준비 할 수 있다면 대단히 감사하겠습니다.

뿡뿡

누군가이 스레드에서 아이디어를 모으고 명명 상황을 개선하기위한 독립형 제안을 준비 할 수 있다면 대단히 감사하겠습니다.

이것은 libs 팀이 현재 API를있는 그대로 안정화하지 않으려 함을 의미합니까? 저는 개인적으로 현재 구현 된 이름 세트보다 더 나은 이름을 생각 해낸 사람이 없다고 생각하므로 그러한 제안을 할 수는 없지만 이러한 API가 안정화되는 것을 보는 데 많은 관심이 있습니다. 그래서 libs 팀의 누군가가 선호하는 이름을 가지고 있다면 : shipit :

많은 동료들과 함께 이것을 Bikeshedded하고 @anp 는 DePin 제안했습니다. 이것은 Unpin 의 "not pin"의미를 제거하고 유형에 대해 이야기하고 있음을 강조하기 때문에 제가 실제로 꽤 좋아하는 DePin . Pin 'd가 될 수 있습니다.

@Kimundi 당신 또는 libs 팀의 누군가가 명시적인 "fcp 관심사"를 등록하여 FCP에서이 문제를 제거하고 "해결해야 할 몇 가지 사항"이 의미하는 바를 더 명확하게 설명해 주시겠습니까?

@rfcbot 문제 고정 해제 이름 지정

FCP가 입력되면 이것이 실제로 작동하는지 확실하지 않지만 Unpin 특성의 이름 지정에 대해 공식적인 차단 문제를 제기하고 싶습니다. Unpin 특성은 API에 매우 중요한 것으로 보이며 "이중 네거티브"(위에서 설명했듯이)는 읽을 때마다 저를 던집니다.

다양한 이름에 대한 많은 댓글이 있지만 안타깝게도 아직 너무 흥분되지는 않습니다. 내 "좋아하는 항목"은 여전히 MoveFromPin 또는 Relocate 라인을 따라 있습니다 (이런 의견이 너무 많아서 어떻게 검토할지 모르겠습니다).

저는 개인적으로 Pin 자체의 이름과 Unpin 특성을 구현하지 않는 ZST의 경우 Pinned 라는 이름에 동의합니다.

나는 Unpin 의 이름이 여기에서 큰 논쟁의 포인트라는 @alexcrichton에 전적으로 동의합니다. 제안 된 기능 자체에 대해 볼 수있는 한 기술적 인 문제는 없다고 생각합니다 (많은 댓글이 있기 때문에 무언가를 놓쳤을 수도 있습니다).

나는 아직도 생각 Pinned 있다 이상한 이름 뭔가가 포함 된 때문에 ZST에 대한 Pinned 정말 고정되지 .. 그냥하지 Unpin . PhantomPinned (# 55992에서 이름이 변경되었으므로)에는 ZST가 약 Unpin _really_ 일 때 Pin 참조한다는 점에서 동일한 문제가 있습니다.

나는 또한이 기능의 미묘함을 감안할 때 문서에 더 많은 작업이 필요하다고 생각하지만 아마도 차단기로 간주되지 않을 것입니다.

또한 @Kimundi , libs 팀이이 문제를 해결하는 데 조금 더 많은 시간을 할애한다는 사실을 알게되어 기쁩니다. 불필요한 자전거 흘리기와 비슷해 보일 수 있지만,이 기능의 학습 능력을 향상시키는 것이 매우 중요하다고 생각합니다.

Pinned 여전히 이상하다고 느끼고 PhantomPinned 이 더 나아지지 않는다고 @jonhoo 와 동의했습니다 (팬텀 방식으로도 고정되지 않음). Unpin 의 좋은 이름을 찾으면 Pinned 은 자연스럽게 Not{NewNameForUnpin} 로 이름이 변경 될 것입니다.

정말 우리가 논의하고있는 더 많은 시간을 할애 할 필요가 있다고 생각하지 않습니다 PhantomPinned 이러한 유형의 거의 최종 사용자에게 표시되지 않습니다 -. PhantomNotUnpin / PhantomNotDePin / PhantomNotMoveFromPin / 등은 더 이상 일반화되지 않거나 이미 충분히 익숙한 사용자에게 API를 다소 명확하게 만들지 않습니다. API를 사용하여 PhantomPinned 대한 합법적 인 사용을 찾았습니다.

간단한 아이디어 : Move 및 ZST Anchor .

모든 유형입니다 Move 그것이 포함하지 않는 한, 수 Anchor 그것은 충실하게 그 Pin .
Anchor: !Move 직관적으로 이해가되는 방식이 마음에 듭니다.

나는 우리가 PhantomPinned 에 특별히 시간을 할애한다고 제안하는 것은 아니지만, Unpin 에 착륙 한 것이 무엇이든지 작동 할 가능성이 있기 때문에 열린 마음을 유지하는 것이 낮은 노력이라고 생각합니다. PhantomPinned 도 마찬가지입니다.

우리는 Move 다루고 왜 부적절한 지 여러 번 설명했습니다. 모든 유형은 고정 될 때까지 움직일 수 있습니다. 마찬가지로 Anchor 이 (가) 이전에 제안되었지만 Unpin ing / Move ing에서 옵트 아웃하는 데 사용되는 이름이 명확하지 않습니다.

@stjepang !Unpin 것이 실제로 이동을 방해하지 않기 때문에 Move 이 (가) 얼마 전에 폐기 된 것 같습니다. 유형은 아래 경우에만입니다 Pin , 그리고 그것을하지 않습니다 Unpin 당신이 그것을 움직이지 "계약 의무"됩니다.

원래 코멘트 @withoutboats 는 다음과

Pin 래퍼는 참조하는 메모리를 제자리에 "고정"하도록 포인터를 수정합니다.

값이 "고정"되지 않았기 때문에 유형이 Unpin 구현하는 것이 이상하다고 생각합니다. 그러나 "이동하기에 안전한"값에 대해 이야기하는 것이 좋습니다. 우리는 무엇을 이름을 변경하는 경우 Unpin 에 MoveSafe ?

UnwindSafe 특성을 고려하십시오. 이것은 단지 "힌팅"마커 특성 일 뿐이며 구현하기에 안전합니다. !UnwindSafe 값이 catch_unwind 경계 ( AssertUnwindSafe )를 넘게하면 불변성을 무효화하여 "파괴"합니다.

마찬가지로 !Unpin / !MoveSafe 값이있는 경우에도 (물론) 이동할 수 있지만 자체 참조를 무효화하여 "중단"합니다. 개념은 비슷해 보입니다.

Unpin 특성 MoveSafe 합니다. Pin 뒤에서 메모리 밖으로 이동할 수있는 값에 관한 것이 아닌 것 같습니다. 오히려 이동할 때 "파괴"되지 않는 값에 관한 것입니다.

MoveSafe 에는 Move 와 동일한 문제가 있습니다. 모든 유형의 값을 안전하게 이동할 수 있습니다. 고정 된 후에 만 ​​값을 이동할 수 없습니다.

MoveSafe 에는 Move 와 동일한 문제가 있습니다. 모든 유형의 값을 안전하게 이동할 수 있습니다.

맞습니다.하지만 UnwindSafe 에서처럼 "안전함"의 다른 의미입니다. 어쨌든, 나는 Relocate 또는 그런 종류의 어떤 것도 괜찮을 것입니다.

요약하면, 트레이 트 이름은 DePin , Unpin 또는 이름에 "pin"이있는 어떤 것도 아니어야한다고 생각합니다. 나에게 그것은 혼란의 주요 원인입니다. 특성은 실제로 Pin 의 족쇄에서 나온 "탈출 해치"가 아닙니다. 특성은 이동할 때 값이 무효화되지 않는다고 말합니다.

Pin 와 Unpin 는 완전히 별개의 것으로 보입니다. :)

나는 정반대를 느낀다.). 특성은 기본 값의 이동성에 대한 제약을 의미있게 표현하는 유일한 유형 인 Pin에 대해서만 의미가 있습니다. Pin이 없으면 Unpin은 완전히 의미가 없습니다.

저는 핀 보드에 ​​무언가를 올려 놓는 것으로 고정을 생각하고 싶습니다. 보드에 고정 된 개체의 핀을 제거하면 개체를 이동할 수 있습니다. 핀 제거는 고정 해제입니다.
저는 Unpin 이름이 마음에

나는 또한 어떻게! Unpin이 이중 부정이고 혼란을 일으킬 수 있는지 볼 수 있습니다. 하지만 얼마나 자주 !Unpin 를 써야하는지 궁금합니다.

Unpin에 사용할 수있는 다른 이름은 Detach 입니다. 핀 보드 비유로 돌아가서, 당신은 _Unpin_이 아니라 객체에서 Pin을 _Detach_ 할 것입니다.

DePin 정말 좋아하는 것 같아요! 지금까지 제가 가장 좋아하는 단어입니다. 간결하고 형용사가 아닌 동사가 분명하며 !DePin 꽤 명확 해 보입니다 ( "고정 해제 할 수 없음").

값이 "고정"되지 않았기 때문에 유형이 Unpin을 구현하는 것이 이상하다고 생각합니다. 메모리가 그렇습니다.

값은 메모리에 고정됩니다. 하지만 여기에서도 가치가 매우 중요합니다. 저에게 메모리 고정은 참조 할 수없는 정도를 유지하는 것이지만 mem::swap 위반되지는 않습니다. 값을 메모리에 고정하는 것은 고정 된 값을 다른 곳으로 이동하지 않는 것입니다. 정확히 Pin 입니다.

나는 또한 어떻게! Unpin이 이중 부정이고 혼란을 일으킬 수 있는지 볼 수 있습니다. 그러나 얼마나 자주 써야할지 궁금합니다!

이름이 혼란스럽지 않다고 말하면 들립니다. 저와이 스레드의 많은 다른 사람들이 이름 지정에 혼란스러워했습니다.

손에 코드가 없지만 선물을 처음 사용하려고 할 때 impl Future<Output=T> 를 반환하는 함수를 원했습니다. 무슨 일이 일어 났는지 기억할 수 없지만 T와 Unpin에 대해 불평하는 형편없는 컴파일러 오류가 즉시 발생했습니다. 내가 대답해야 할 질문은 "T를 고정 해제로만 제한하는 것이 안전합니까?"였습니다. 그로 인해 약 2 시간 동안 심연을 응시했습니다.

"오, 좋습니다. 핀이 의미하는 것이라면. 그래서 Unpin은 .. Box를 의미합니까? 그게 왜 특성입니까?"

"잠깐만 요, impl !Unpin ? 왜 impl Pin 가 아니죠?"

"Right, Pin 및 Unpin ...은 반대가 아닙니다. 완전히 다른 것입니다. 잠깐, Unpin이 또 무엇을 의미합니까? 왜 그렇게 부르나요?"

"도대체 !Unpin 은 무엇을 의미합니까? ... 다른 것이 아니라 핀 것입니까? Hrrrgh"

여전히 이것이 내 머릿속에서 이해되는 유일한 방법은 '고정 해제'를 '위치 변경 가능'으로 바꾸는 것입니다. "유형은 메모리에서 재배치 할 수 없습니다"는 완전히 의미가 있습니다. 그러나 Pin이 무엇을하는지 알기 만해도 "type is not unpin"은 혼란 스럽습니다.

Unpin 을 Relocatable (또는 Relocate )로 바꾸면 내 투표 🗳를 얻습니다. 그러나 고정 해제보다 더 나은 다른 제안을 찾을 수 있습니다.

특성은 기본 값의 이동성에 대한 제약을 의미있게 표현하는 유일한 유형 인 Pin에 대해서만 의미가 있습니다. Pin이 없으면 Unpin은 완전히 의미가 없습니다.

이것에 대해 요점을두기 위해, 핀에 대한 보장은 전적으로 유형이 아닌 특정 행동 에 대한 것입니다. 예를 들어 () 를 산출하는 생성기 함수는 반복적으로 재개하여 FnOnce 를 사소하게 구현할 수 있습니다. 이 유형은 Unpin 구현하지 않을 수 있지만 수율 상태가 자체 참조 일 수 있기 때문에 FnOnce 인터페이스 (자체 이동)는 FnOnce 때 아직 고정되지 않았기 때문에 완전히 안전합니다. Unpin 는 유형의 일부 고유 속성이 아니라 유형이 고정되면 (즉, 이동) 안전하다고 주장되는 동작의 종류에 관한 것입니다.

아이러니하게도 저는 Unpin 이름 지정이 과거에 확실히 논쟁 이 되었지만, 그 논쟁이 Move 를 Unpin 로 대체하기로 결정했을 때였습니다. 분명한 개선입니다. 그리고 종종 나중에 그것을 깨달을 때가 있습니다. 현재 디자인은 이전에 비해 확실히 개선 되었지만 아직 더 개선 할 여지가 있습니다. 이것이 내가이 일에서 오는 방향입니다.

고정 해제는 형식의 일부 고유 속성이 아니라 형식이 고정되면 (즉, 이동) 안전하다고 주장되는 동작의 종류에 관한 것입니다.

고정 된 동작은 그냥 공유되어있는 문제 / 불변 같은 유형의 고유 속성입니다. 나는 이 블로그 포스트 에서 훨씬 더 자세히 다루었 다.

@RalfJung 우리는 서로 과거에 말하고 있습니다. 자기 참조 유형이 "이동할 수 없음"이라는 혼란이 많이 있습니다. 이것은 정확하지 않고 이동할 수없는 특정 상태를 입력 할 수 있지만 다른 상태에있는 동안에는 완벽하게 안전합니다. 로 이동 (우리의 API는 예를 들어 그들에게 콤비를 적용하는 그들을 이동하는 기능에 의존하거나로를 이동하기 Pin<Box<>> ). 나는 이러한 유형이 "이동할 수없는"경우가 아님을 명확히하려고합니다.

아, 그럼 동의합니다. !DePin 유형은 항상 고정되는 것은

@cramertj @withoutboats 내가 아직 생각할 수 없었던 한 가지는 Unpin 이름을 바꾸는 것에 반대 합니까? 이름을 바꿔야한다는 데 동의한다고 생각하는 것 같지는 않지만 반대하는 건지 모르겠습니다.

나는 개인적으로 여기서 주요 문제가 Unpin 라는 이름에 있다고 생각하지 않으며 "만약 이름을 바꿀 수 있다면 모든 것이 직관적 일 것"이라고 생각합니다. 이름을 바꾸는 것이 약간 도움이 될 수 있지만 (여기서 Relocate / DePin은 멋지게 보입니다 ...), 주요 복잡성은 자체 고정이라는 개념에서 비롯된 것 같습니다. 확실히 이해하거나 설명하기 가장 쉬운 개념은 아닙니다. 거의 없습니다.

따라서 core::pin 모듈의 문서를 _ 대단하게 _ 강화하고 더 많은 예제를 포함해야한다고 생각합니다. 좋은 예는 표준 사용 사례뿐만 아니라 안전하지 않은 기능 및 불건전 한 구현의 사용을 보여줍니다.

@alexcrichton 저는 이름 변경에 반대 하지 않습니다. 내 생각 Unpin 잘 이미,하지만 난 괜찮 것 DePin 내가 제안하는 이유입니다. RemoveFromPin 가 가장 분명하게 "올바른"것이지만, 구문 솔트의 요점에 대해서는 장황합니다. 그래서 저는 그 이름을 구체적으로 반대 할 것 같습니다. 그러나 저는 모두가 동의하는 이름이 최고라는 것을 알 때까지 안정화를 무기한 미루는 것에 반대합니다. API에는 Unpin 의 이름 때문에 극적으로 더 좋거나 나쁘게 만들어지지 않는 몇 가지 고유 한 복잡성이 있다고 생각합니다 futures_api 주변의 코드, 문서 및 토론에 대한 더 많은 변동을 방지하기 위해 곧 안정화를 추진하고 싶습니다 (그러면 futures_api 를 안정화 할 수있는 부분을 제자리에 배치 할 수 있습니다. 그 자체). 의견이있는 모든 사람이 해결책을 제시하고이를 해결할 수있는 더 높은 대역폭의 기회를 가질 수 있도록 이름을 정하는 전용 VC 회의를 예약해야할까요?

내 투표는 std::pin::Reloc (이전)입니다.

나는 두 가지 매우 가상의 상황 (실제로는 하나이지만 두 가지 다른 실행)을 가지고 있는데, 그 중 허용 여부를 명시 적으로 언급해도 괜찮습니다.

Unpin 는 고정 된 유형 상태에있는 동안 T 의 모든 상태 ( T: Unpin ) 상태에서 전환하는 것이 사소하다는 것을 나타냅니다 (그 용어를 올바르게 기억하고 있기를 바랍니다). @RalfJung 의 블로그 게시물 중 하나에서 고정되지 않은 유형 상태로. 이것이 Pin 가 &mut T 나눠 줄 수있는 이유입니다.

따라서 고정 된 유형 상태에있는 동안 항상 모든 Woof 상태에서 고정되지 않은 유형으로 전환 할 수있는 Woof 유형을 만들고 싶다고 가정 해 보겠습니다 Woof 상태이지만 그렇게하는 것은 사소한 일이 아니며 Unpin 구현할 수 없습니다. Woof 에 fn unpin(self: Pin<Box<Woof>>) -> Box<Woof> 와 같은 함수가 허용됩니까?

고정 된 상태에서 고정되지 않은 상태로 전환 할 수있는 유형 Meow 및 fn unpin(self: Pin<Box<Meow>>) -> Result<Box<Meow>, Pin<Box<Meow>>> 와 같은 함수도 마찬가지입니다.

바이크 쉐딩을위한 나의 2 캐럿 :

내가 올바르게 이해한다면, Unpin 실제 의미는 " Pin 는 나에게 영향을 미치지 않습니다"입니다.

BypassPin 또는 IgnorePin 어떻습니까?

따라서 고정 된 유형 상태에있는 동안 항상 모든 Woof 상태에서 고정되지 않은 유형 상태로 전환 할 수있는 유형 Woof를 만들고 싶다고 가정 해 보겠습니다.하지만 그렇게하는 것이 사소한 것은 아닙니다. Unpin을 구현할 수없는 경우 Woof가 fn unpin (self : Pin>)-> 상자?

네, 가능합니다. 예를 들어, Woof 가 침입 연결 목록의 요소 인 경우 목록에서 요소를 제거하는 기능을 제공하고 동시에 Pin 를 제거 할 수 있습니다. -enqueued Woof s, 두 유형 상태는 동일하므로 고정 해제 할 수 있습니다.)

Relocate 은 (는) RePin 와 (과) 동일한 문제를 가지고 있습니다. 이는 값을 완전히 고정 해제하지 않고 고정 된 위치에서 다른 위치로 값을 이동할 수있는 작업을 의미 할 수 있습니다. RePin 보다 덜 강력한 의미이지만 여전히 약간 혼란스러워 보입니다.

값을 완전히 고정 해제하지 않고 고정 된 한 위치에서 다른 위치로 값을 이동할 수있는 작업을 의미 할 수 있습니다.

이것이 정확히이 특성에 관한 것은 아니지만, 전적으로 잘못된 것은 아닙니다. 대부분의 사용 사례에서 값을 고정 된 위치에서 다른 위치로 이동하는 것은 값을 자유롭게 사용하는 것만 큼 치명적입니다. 실제로 누구나 Pin<Box<T>> 만들 수 있다는 점을 감안할 때 여기에서 근본적인 구별을하는 이유도 알 수 없습니다.

대부분의 사용 사례에서 값을 고정 된 위치에서 다른 위치로 이동하는 것은 값을 자유롭게 사용하는 것만 큼 치명적입니다.

그렇기 때문에 해당 작업을 유형에 추가하는 트레이 트가 유용 할 수 있습니다 (내부 참조 업데이트와 같은 작업을 수행해야 할 수 있으므로 Unpin 와 같은 마커 트레이 트일 수 없음). 나는 지금 이와 같은 것을 추가 할 것을 제안하는 것이 아니라, 이름이 혼동 될 수있는 미래 ( std 또는 제 3 자)에서 제공되는 것을 볼 수있을뿐입니다.

지금은 강력한 사용 사례를 알지 못하지만 고정 된 컬렉션에 이와 유사한 것을 사용하는 것에 대해 생각했습니다.

좋아, 여기에 몇 가지 생각이 있습니다. 저는 처음에는 PinInert 또는 PinNoGuarantees 같은 이름을 가질 수 있는지 궁금했습니다. 설명이 무엇인지에 대한 설명이기도하지만, 제가 정말로 원하는 것을 생각하는 것은 행동 을 설명하는 특성입니다. 또는 적어도 내 머릿속에서 생각하기가 훨씬 쉬워집니다.

Unpin 한 가지 문제점은 (이유를 잘 모르겠습니다) 의도 된 의미가 "핀에서 제거하고 고정을 해제하는 작업이 안전하다고 생각하는 것입니다. ". 있는 그대로의 특성은 "고정 해제 행위"의 행동을 전달하지만 그것을 읽을 때 나는 그것을 잘 이해하지 못하는 것 같습니다. Pin<T: Unpin> 가 "고정 해제"인 경우 핀에있는 이유는 무엇입니까?

CanUnpin 와 같은 이름이 작동 할 수 있는지 궁금합니다. 이 중 상당수는 어떤 식 으로든 엄격한 보증에 관한 것이 아닙니다 ( Unpin 구현은 핀에서 핀을 제거한다는 의미가 아니라 핀에서 제거 할 수 있음을 의미합니다). 어떻게 들리나요? CanUnpin 은 다른 사람들이 충분히 읽을 수 있습니까? 충분히 짧습니까?

( Can 접두사를 사용하면 동사를 훨씬 더 쉽게 전달할 수 있으며 핀에서 제거 할

무관 한 또 다른 접선으로서, 앞서 언급하지 않은 한 가지 (죄송합니다!)는 위의 모든 방법이 반드시 고유 한 방법이어야한다고 생각하지 않는다는 것입니다. 우리는 이미 추론 및 충돌 메서드와 관련된 많은 버그를 가지고 있으며 Deref 도 구현하는 유형에 as_ref 및 as_mut 와 같은 매우 일반적인 이름을 추가하는 것이 문제인 것 같습니다. 일어나기를 기다리고 있습니다.

이러한 작업은 위험한 위치를 정당화하기에 충분할 정도로 일반적으로 발생합니까? (본질적으로) 아니면 관련 기능의 안전한 경로를 위장 할 수있을 정도로 드물게 사용됩니까?

지금이 게임에 스킨이있는 것 같기 때문에 CanUnpin 은 (는) Unpinnable 또는 이와 유사한 것에 정신적으로 매우 가까워 보였습니다. 그리고 제 인상은 항상 커뮤니티가 이러한 종류의 수정자를 눈살을 찌푸리는 것입니다. 대부분의 특성은 유형이 취할 수있는 조치를 설명하므로 특성 이름입니다. impl 자체는 그런 의미에서 묵시적인 "can"또는 "-able"입니다. 결정된 것이 무엇이든 (그리고 이름은 여기에 언급 된 정도로 중요하지 않습니다. 사용자가 거의 없습니다. 사용자가 거의 없을 것입니다.) 여기에서 질문을 해결하는 데 긴급함을 느끼도록 모든 사람에게 권장합니다. 저는이 안정화에 대해 흥분하고 많은 사람들이 있다는 것을 알고 있습니다!

헉헉

Unpin 한 가지 문제는 (이유를 잘 모르겠습니다) 의도 된 의미가 "핀에서 제거하고 고정을 해제하는 작업이 안전하다고 생각하는 것입니다. ".

T: Unpin 을 " T 가 Pin "에 면역되어 있다고 생각하면 어떻게됩니까? 그런 다음 Pin<T: Unpin> 가있는 경우 고정에 영향을받지 않는 Pin 내부에 값이 있음을 의미하므로 고정이 여기에 효과적으로 적용됩니다.

즉, Unpin Pin 무력화 합니다. 솔직히 말해서, 너무 많은 논의 끝에 나는 이것을 내면화했고 지금은 의미가 있습니다. 😆

이 중 상당수는 어떤 식 으로든 확실한 보증에 관한 것이 아닙니다 ( Unpin 구현은 핀에서 핀을 제거한다는 의미가 아니라 핀에서 제거 할 수 있음을 의미합니다).

이에 대한 대위법은 Send 특성입니다. 그것은 당신이 가치를 보내드립니다 것을 의미하지 않는다, 그것은 단지 당신이 그것을 보낼 수 있다는 것을 의미합니다.

@anp 나는 CanUnpin 이 (가) 훌륭한 이름이 아니라는 데 동의합니다. 더 나은 이름을 찾기 위해 최선을 다하고 있습니다 ! 모든 제안이 기본적으로 Unpin 이름을 변경해야한다고 생각하는 것과 동일한 이유로 인해 이름이 변경되어야한다고 생각하는 사람은 거의없는 것 같습니다.

또한 모든 안정화는 다른 모든 변경 사항과 마찬가지로 열차를 타며 다음 주에 릴리스되면 확실히 해당 릴리스에 포함되지 않으며 다음 릴리스의 후보가 될 것입니다. 즉, 7 주, 거의 2 개월 동안이 모든 것을 최대한 빨리 처리 할 수 ​​있습니다. 나는 긴박성이 필요하다는 데 동의하지만, "월요일 전에이 문제를 해결하자"가 아니라 "이 긴박성을 잊지 말자"에 불과합니다.

@stjepang 저도 너무 많이 생각하고 나서 Unpin 익숙해졌습니다! 이 시점에서 모든 대체 이름은 매우 흐릿 해 보이므로 더 나은 문서화에 만족할 지점에 도달했습니다. 나는 이상적으로는 Pin API에 대해 잘 모르는 사람을 찾고 나중에 언급 한 문서를 읽고 학습에 충분한 지 다시 확인하고 싶습니다.

또한이 문제에 특히 중요하다고 느끼기 때문에 개선 된 문서에 대한 안정화를 공식적으로 차단하고 싶습니다.

@rfcbot 우려 문서 개선

구체적으로 더 나은 문서가 필요하다고 생각하는 것은 다음과 같습니다.

• 각 방법이 왜 안전한지 및 / 또는 왜 안전하지 않은지에 대한 더 많은 산문. 예를 들어 P 의 DerefMut 구현 계약이 Pin::new_unchecked 에 문서화되어 있지 않습니다.
• 각 unsafe 함수에는 왜 그것이 안전하지 않은지에 대한 코드 예제 또는 적어도 잘못 될 수있는 일련의 단계에 대한 명확한 설명이 있어야합니다.
• 모듈 문서는 단순히 Pin 가 무엇인지, 그리고 그 의미를 넘어서 더 자세히 설명 할 수 있다고 생각합니다. 나는 그들이 "어떻게 이것이 일반적인 부동 형이 아니라 그것의 형태"또는 "예를 들어 선물과 같이 실제로 사용되는 Pin "와 같은 정보로부터 이익을 얻을 것이라고 생각한다.
• 설명서 또는 코드 예제에서 제네릭 및 Unpin 예제를보고 싶습니다. 예를 들어 미래의 많은 결합자가 이것을 처리해야하는 것처럼 들리며 유사하게 일부 결합자는이를 특별히 요구 합니다. 제네릭과 어떻게 작동하는지와 어떻게 작동하는지에 대한 몇 가지 사용 사례는 Unpin 이해하는 데 도움이 될 수 있습니다.

다른 사람들도 문서에 추가 할 구체적인 실행 가능한 항목이 있는지도 궁금합니다!

다음으로 as_ref self -질문을 공식적으로 차단하고 싶지만이 문제가 빨리 해결 될 것 같습니다. (이 문제를 더 일찍 제기하는 것을 기억하지 못해 죄송합니다)

@rfcbot 우려 자체 방법

이는 as_ref , as_mut , get_ref , get_mut , into_ref 및 set 을 Pin 유형. 이 제안은 메서드 충돌로 인해 스마트 포인터에 대해이 작업을 수행하지 않는다고 언급하지만, 경험에 따르면 오늘날 구현 된 Pin API가 일관성이 없으며 종종 방해가되는 경우가 많습니다.

그러나 이러한 메서드 이름은 매우 짧고 달콤한 이름이며 생태계 전체에서 흔히 볼 수 있습니다. libs 팀은 과거에 트레이 트 구현 등을 추가하는 끝없는 일련의 버그에 부딪 쳤으며 다양한 상자에서 기존 트레이 트 메서드와 충돌을 일으 킵니다. 이러한 방법은 이름 때문에 특히 위험이 높습니다. 또한 이름이 추가 된 향후 이름이 충돌 할 위험이 높은 경우에도 앞으로 Pin 에 더 많은 메서드를 추가 할 수 있는지 여부는 불분명합니다.

저는 우리가 관습과의 차이를 다시 생각하도록하고 싶습니다. 저는 개인적으로 특히 그 결과에 대해 걱정하고 있으며 이러한 위험을 피할 수있는 중간 지점을 찾을 수 있다면 좋을 것이라고 생각합니다.

그리고 제가이 문제를 해결하는 동안 마지막으로 알아 차린 점이 있습니다. 다시 한 번이 문제를 해결하는 것이 매우 빠르다고 생각합니다.

@rfcbot 우려 상자 고정 대 상자 핀

이름나요 Box::pin 고려 된 Box::pinned ? Pinned 및 / 또는 PhantomPinned 존재로 이름이 반환 유형과 일치 할 수 있다면 깔끔 할 것 같습니다!

@alexcrichton 특히 아무것도에 대해 당신을 설득 가지고 MoveFromPin 로 옵션 ? 나는 당신이 일찍 그것에 대해 호의를 베푸는 것을 봅니다 (그리고 여러 사람들도 그것을 좋아하는 것 같았습니다). 기록을 위해 내가 기억하거나 Ctrl + F-ing으로 빠르게 찾을 수있는 직접적인 반대는 "전체 문구 인 이름은 ... 매우 단관적일 것" (@withoutboats)이며 "너무 말이 많다

나는 "나는 그것에 대해 너무 많이 생각한 후에 익숙해졌다"라는 맥락에서 동기가 나를 다소 불안하게 만든다는 것을 인정해야한다. 인간은 본질적으로 모든 것에 익숙해지고 사후 합리화 할 수 있습니다. 이름이 무엇이든 우리 가 결국 익숙해 분명히 -suboptimal 이름을 선택하는 이유는 바로 그 이유입니다 existential type 그들이 영구적되고 피하려고 다른 경우 임시직, 등.)

우연히 더 신선한 두뇌로 일을 할 다른 사람들보다 숙련 된 사용자 (우리 모두가 그렇습니다!)의 관점에 특권을 부여하는 것은 우리가 만드는 것에 대해 항상 경계해야한다고 생각하는 실수 입니다 .

확실히 std lib의 스타일은 아니지만, CanUnpin 는 특정 부분이 다른 부분과 어떻게 잘 어울리는 지 더 명확하게 보여줍니다.

문서를 읽지 않고 초보자에게 Unpin 의 의미를 설명하는 이름을 발명하는 것은 불가능합니다. Send 및 Sync 또한 초보자에게는 이해하기 어렵지만 멋지고 간결 해 보이며 Unpin 도 마찬가지입니다. 이 이름이 의미하는 바를 모르는 경우 해당 문서 를 읽어야합니다.

@valff 맞습니다. 그러나 문서를 읽고 고정 작동 방식을 이해 한 사람이 꽤 많지만 Unpin 이름은 여전히 심각한 정신적 어려움을 유발하는 반면 다른 이름은 덜 유발합니다.

@glaebhoerl 오, 제가 개인적으로 현재 Unpin 보다 MoveFromPin 또는 CanUnpin 팬이 더 많다는 점을 명확히해서 죄송합니다. 결론을 내리는 데 도움을 주려는 것뿐입니다!

나는 현재의 제안을 이해하려고 노력했는데, 아마도 이런 종류의 진행 보고서가 이름 지정에 대한 추가적인 빛을 비출 수있을 것입니다.

• Drop 까지 Pin 보장을 안정적인 주소로 연장하면 Pin 생성자에게 추가 요구 사항이 적용됩니다. unsafe fn new_unchecked(pointer: P) -> Pin<P> 를 호출하는 데 필요한 전제 조건이 직접 언급 되었다면 유용 할 것입니다. Pin 가 어떻게 생성 될 수 있는지 이해하면 그들의 개념 인 imo를 이해하는 데 큰 도움이됩니다.
• we agreed that we are ready to stabilize them with no major API changes. 시작하는 추적 문제에 언급 된 요약에는 많은 오래된 API가 포함되어 있습니다. 동시에 Drop 및 관련 핀 투영에 대한 많은 통찰력도 포함되어 있습니다. 또한이 보고서에서 찾을 수없는 글 머리 기호 1에 언급 된 추가 보증에 대한 명시적인 공식을 포함합니다. 이 오래된 정보와 새로운 정보의 혼합은 약간 혼란 스러웠습니다. 모든 정보를이 문제로 옮기거나 오래된 단락을 나타내는 것을 고려하십시오.
• 추가 보증을 slight extension 라고하므로이를 선택 해제 할 수있는 방법이있을 것으로 예상했습니다. 고정은 포인터가 드롭 될 때까지 해당 포인터에 유형 상태를 전달하므로이 유형 상태에서 '정상'상태로 되돌아 갈 수 있습니다. 사실 처음에는 Unpin 라고 생각했지만 Unpin 가 실제로는 좀 더 강하다고 생각합니다. 고정 된 상태는 마음대로 고정 해제 된 상태로 자유롭게 전환 될 수 있다고 말합니다. 이와 관련하여 현재 인터페이스는 최소 수준이지만 Unpin 는 핀 상태를 필요로하는 내부 불변을 제거하는 유형에 대한 작업과 혼동 될 수 있습니다 (예 : Drop 의 소프트 버전). .

설명 : 저는 개인적으로 다른 이름보다 MoveFromPin 를 선호하지만 인위적이고 투박합니다.

@alexcrichton 에서 이미 요청한 문서 개선 사항 외에도 실행 가능한 구체적 실행 가능한 주요 항목은 map_unchecked 및 map_unchecked_mut 핀 투영에 대한 필드 규칙 뒤에있는 이유를 설명하는 것입니다. 라인을 따라 뭔가 :

핀은 삭제 될 때까지 참조 된 데이터를 이동하지 않을 것을 약속합니다. 구조체의 필드가 포함 된 구조체 이후에 삭제되기 때문에 핀 상태는 구조체 자체의 Drop 구현을 넘어 확장됩니다. 필드에 투영하면 구조체 소멸자 내에서 필드에서 이동하지 않을 것을 약속합니다.

자동 파생 마커 트레이 트의 이름 ElidePin 은 어떻습니까?

유형이 항상 고정 해제 된 것처럼 처리되거나 동작 할 수 있음을 포착합니다. 그리고 !ElidePin 도 매우 명확 해 보이지만 주관적 일 수 있습니다.

표준 마커에는 고정을 이해하기위한 완벽한 이름도 없습니다. Pinned 는 포함하는 구조체 자체가 고정되어 있지만 고정은 포인터에 적용되고 명시적인 작업 후에 만 ​​적용된다는 개념을 불러 일으키는 것 같습니다. 이것은 그다지 중요하지는 않지만 중요하지도 않습니다. 특히 자체 참조 유형에 대한 구현에서 처음 발견되는 유형일 수 있기 때문입니다.

MoveFromUnpin / RemoveFromUnpin 대한 나의 일반적인 반대는 그들이 너무 말이 너무 많아서 수동 Future 구현의 인체 공학을 퇴보시킬 뿐이라는 것입니다. CanUnpin / DePin 둘 다 괜찮아 보입니다. Unpin 가 Read / Write 의 패턴을 따르는 것이 더 분명했으면합니다. /기타. 그러나 그것은 사람들에게 직관적이지 않은 것 같습니다. 그래서 나는 구문 적 소금처럼 보이지 않고 이것을 더 명확하게 만드는 것을 +1하겠습니다.

NotWhateverUnpinBecomes 이 아마도 Pinned 의 가장 좋은 이름이라는 데 동의합니다. 즉, Adhere 는주의를 기울이고 고수하는 것을 의미합니다. : slightly_smiling_face :

CanUnpin / DePin 둘 다 나에게 괜찮아 보입니다. Unpin이 Read / Write / etc의 패턴을 따르는 것이 더 분명했으면합니다.

Read 와 달리 Unpin 어렵게 만드는 것 중 하나는 마커 특성이라는 것입니다. Read 메서드가 있기 때문에 이해하기 쉽습니다. Read::read -알아야 할 모든 것이 trait 있습니다. 경우 x 이다 Read 내가 호출 할 수 있음을 이해 x.read() - 유사 write 에 대해 Write 는 것을 설명하기 힘들다 등, X implementation Unpin 는 Pin<Ptr<X>> DerefMut 구현한다는 것을 의미합니다-이는 마치 X 처럼 처리 할 수 ​​있음을 의미합니다.

Read :: read 메소드가 있기 때문에 읽기는 이해하기 쉽습니다.

auto trait 정의 + GAT에 항상 적용 가능한 메서드를 추가 할 수만 있다면 Unpin::unpin - fn unpin<P: DerefFamily>(self: Pin<P::Deref<Self>>) -> P::Deref<Self> )를 가질 수 있습니다. ..... 두 번째 생각에, 나는 그것이 누구를 덜 혼란스럽게 만들 것이라고 생각하지 않습니다.)

(좀 더 진지하게 말씀 드리면, Pin<P<T>> 에서 P<T> 로 이동하는 데 Pin::unpin 를 지원하겠습니다)

나는 Pin :: unpin에서 Pin에서 이동을 지원할 것입니다.

> ~ P

이것은 현재 이름 자체와 마찬가지로 내 머리 속의 두 용어를 혼동합니다. unpin 메소드 fn unborrow(&'_ T) 또는 fn unmove(??) 가있는 것과 같은 비교를 위해 유형 상태의 보장을 반전하는 것과 매우 유사하게 들립니다. pin 는 유형을 나타내는 일부 메모리가 Drop::drop ed가 될 때까지 보장을 제공하므로 실제로 상태를 되 돌리지 않습니다. 유형은 다른 모든 표현이 동등한 보장을 유지함을 보장 할 뿐이므로이를 무시할 수 있습니다. . 이것은 또한 마커 특성과 io::Read 와 같은 것 사이에 내가 보는 주요 차이점입니다. 하나는 컴파일러 또는 언어에 대한 작업을 활성화하고 다른 하나는 프로그래머에 대한 작업을 활성화합니다.

또한 정확한 타이핑만으로는이를 정확하게 표현할 수 없다는 것이 주요 포인트입니다. 동작을 호출하려면 unpin 역 기능이 있었다 것처럼 들리게 pin . 또한 함수라는 것은 그러한 고정 해제 작업이 어떻게 든 계산 작업에 묶여 있음을 약간 잘못 암시합니다. 예를 들어 into_pointer() 는 더 확립 된 명명 규칙을 따르면 이와 관련하여 더 낫습니다.

마지막으로, 계산 작업과 함께 unpin 함수가있는 유형에 대한 잠재력이 있다고 생각합니다. 매우 특별한 내부 불변을 가진 유형은 fn unpin(self: Pin<&'a mut T>) -> &'a mut 인터페이스를 제공 할 수있는 방식으로 내부 상태를 '고정'할 수 있으며, 여기서는 평생 동안 Pin 의 모든 보장을 기꺼이 상실합니다. 'a 이 경우 위의 두 가지 사항이 더 이상 적용되지 않습니다. 이러한 함수는 동일한 메모리 위치에서 삭제 및 재구성하는 것과 동일한 효과가있는 것처럼 상상할 수 있습니다 (따라서 실제로 유형 상태를 제거함). 예를 들어 일부 자체 참조를 동적 할당으로 이동하여 계산을 포함 할 수 있습니다.

혼란스러운 이름이 라이브러리 디자이너와 구현자가이 두 가지 아이디어를 결합하여 혼란스럽지 않은 이름을 선택하는 것을 더 어렵게 만든다면 불행 할 것입니다.

MoveFromUnpin / RemoveFromUnpin에 대한 나의 일반적인 반대는 그들이 너무 말이 많고 수동 Future 구현의 인체 공학을 퇴보시킬 것이라는 것입니다.

나는 그것이 사실이라고 생각하지 않는다. 특히 MoveFromPin , 그것은 나를 위해 타자하는 것이 합리적이라고 생각한다. 그리고 어떤 종류의 똑똑하거나 멍청한 자동 완성으로 문제는 어쨌든 거의 존재하지 않는다.

인체 공학의 중요한 부분 중 하나는 코드의 가독성과 이해도 여야합니다. Rust는 과거에 이미 무언가를 공격적으로 줄여서 ( fn , mut 등) 약간의 비판을 받아 일부 코드를 읽기 어렵게 만듭니다. 이해하기 훨씬 더 복잡하고 대부분의 사용자를위한 틈새 목적을 충족하는 개념의 경우보다 장황하고 설명적인 이름을 사용하는 것이 완전히 허용되어야합니다.

@rfcbot 고정 해제 명명 해결

Ok 나는 잠시 동안 끓여 왔으며 @withoutboats 와 직접 이것에 대해 이야기했습니다. 나는 이제 적어도 마커 특성으로 Unpin 라는 이름을 사용하는 것이 개인적으로 편안하다는 것을 알게되었습니다. 결과적으로 차단 이의 제기를 제거 할 것입니다 (Libs 팀의 다른 사람들이 다르게 느끼더라도 알려주십시오!)

제가 Unpin 온 주된 이유는 기본적으로 @cramertj가 이미 위에서 말한 것입니다. 우리가 생각 해낼 수 있었던이 특성에 대한 가장 관용적 인 이름입니다. 내가 제안한 다른 모든 특성 이름은 Unpin 부합하는 관용적 기준을 충족하지 못합니다 (또는 적어도 제 생각에는).

"나는 방금이 특성의 이름을 보았고 그것이 무엇을하는지 알고 싶다"에 대한 더 나은 이름이 있다고 생각하지만, 여기서 해결해야 할 올바른 문제라고 생각하지 않습니다. 그것은이 시점에서 나에게 분명 그 우리가 할 수없는, 적어도이 시간에, 또한 관용이 아니라 우리가 다른 문제를 해결 특성 이름에 주변에 전환하고이 특성에 대해 다른 이름을 알아낼. Unpin 이해하는 것은 Send 및 Sync 와 유사하며, 무슨 일이 일어나고 있는지 완전히 이해하려면 설명서를 읽어야합니다.

또 다른 명확한 요점으로 몇 가지 "차단 이의 제기"를 나열했지만 이의 제기 자체를 차단하는 것보다 TODO 항목에 가깝습니다. 나는 그렇게 긴 스레드를 탐색하는 좋은 방법이 없습니다! 그런 맥락에서 지금은 FCP가 1 주일 정도 경과 한 상태에서 언제라도 안정화 PR을 게시해도 괜찮다고 생각합니다. 자체 / 고정 / 고정에 대한 마지막 요점은 여기서 간단히 논의 할 수 있습니다 (필요한 경우 위의 제안으로 남겨 둘 수 있음).

특히 문서화는이 경우 안정화를위한 전제 조건이 아니라고 생각합니다. 이러한 유형이 안정되기 전에 문서를 추가 할 전체주기 (6 주)가 있으며 전체 비동기 / 대기 스토리가 안정되기 전에 여기에 문서를 추가 할 시간이 훨씬 더 많습니다. 현재 거기에있는 것을 개선하는 데 많은 시간이 소요되고 있으며, 지금있는 것은 이미 상당히 유용합니다!

여기서 "특이성"은 무엇을 의미합니까? Reloc[ate] , Escape , Evade , Pluck 또는 Roam 에 대한 단관 어는 무엇입니까? 그것들은 모두 동사이고, 이중 부정 문제가있는 것으로 오인 될 수있는 것은 없습니다.

@alexcrichton Unpin 이 Depin 또는 DePin 보다 관용적으로 간주되는 이유가 있습니까?

나는 Depin 이 매우 견고한 대안이라고 생각하며 Unpin 와 같은 정신적 어려움을 유발하지 않습니다.

한 가지 간단한 이유는 depin이 단어가 아니라 unpin이 있기 때문일 수 있습니다. 개인적으로 Unpin 이해하는 데 문제가 없습니다. 다른 마커 특성의 이름과도 맞다고 생각합니다.

@jimmycuadra Rust에는 stdlib를 포함하여 "진짜"단어가 아닌 이름이 많이 있습니다.

그것이 다른 이름보다 한 이름을 선택하는 중요한 이유로 간주된다면 나는 놀랄 것입니다.

@Pauan 그것은 중요한 이유입니다. 영어 원어민으로서 Depin 는 고정 해제라는 단어가 존재한다는 것을 잊고 하나를 만들려고 한 것처럼 들립니다. "depinning"에 대한 영어 단어는 "unpinning"입니다.

좋은 비유는 "잠금 해제"대신 "잠금 해제"라는 API가있는 경우입니다.

@jaredr by " Read 및 Write 특성과 같은 표준 라이브러리의 확립 된 규칙을 따르는 것을 의미합니다. 우리는 가능한 한 짧고 상황에 적합한 단어가 아닌 이름, 동사의 규칙을 가지고 있습니다.

귀하가 제안한 이름은 모두 가능하지만 Unpin (또는 적어도 내가 생각하기에)이이 특정 작업에 가장 적합합니다 ( "이 유형 고정 해제 가능"보장). 다른 사람의 느슨한 동의어 동안 Unpin , 내가 주로 전용 "고정을 해제"멀리 단어에서 이름을 바꾸는 생각하고 때로는와 같은 연결 전달하지 않는 Pin 로 Unpin 그렇습니다.

나는 그 @withoutboats에 동의 @Pauan Depin 이뿐만 아니라 jives 같은 소리하지 않습니다 Unpin .

@aturon 은 https://github.com/rust-lang/rfcs/pull/2592#issuecomment -438873636에서 다음과 같이 언급했습니다.

Pin 은 &self 대 &mut self 의 선택보다 구현 세부 사항이 아닙니다. 장기적으로 Pin 자체가 언어 지원과 함께 별도의 참조 모드가 될 가능성이 있습니다. 이 모든 경우에서 서명으로 전달되는 것은 수신자에게 부여되는 권한이며 Pin 는 참조에서 이동하는 것을 금지합니다.

표면적으로 이것은 네이티브 &pin 유형 또는 무언가를 나타냅니다 ...하지만 이것이 Pin<&mut T> 등과 어떻게 제곱되는지 확인합니다. @withoutboats , 특히 @cramertj 와의 대화에서 그들은 언어 지원과 함께 별도의 참조 모드에 대한 아이디어와 Pin<T> 에서 얻을 수있는 방법에 대해 전혀 확신하지 못했습니다.

pin 안정화하기 전에 이러한보기를 조정하여 동일한 페이지 wrt에 있는지 확인하는 것이 현명 할 것입니다. 이 중요한 인프라 부분; 그래서 저는 주로 Aaron이 이것에 대해 확장하고 보트와 Taylor가 무게를 측정하기를 원합니다.

다른 것들은 Unpin의 느슨한 동의어이지만 대체로 "unpin"이라는 단어에서 이름을 바꾸는 것일 뿐이며 때로는 Unpin과 동일한 연결을 전달하지 않습니다.

@alexcrichton 이것은 실제로 좋은 일이라고 생각합니까? Send 와 같이 이동 / 복사 (=) 작업에, Sync 에 대여 (&) 작업에 사용합니다. 그러한 연결이 실제로 더 많은 혼란을 야기할까요?

@ crlf0710 그럴지도! 나는 나 자신이 그러한 관계에 동의 할 것인지 확신하지 못한다. Send 및 Sync 는 그들이 활성화하고있는 것 (다른 스레드에 유형을 "보내기"및 스레드 간 액세스를 "동기화")에 대해 더 자세히 설명하며 이름을 지정할 때 시도하지 않았습니다. 한 작업 또는 다른 작업에 가깝게 이름을 지정하지 마십시오.

@alexcrichton 정확히! 그래서 아마도이 특성은 그것이 가능하게하는 것에 관한 것이어야합니다. ( "움직이는 (여기에 동사) Pin ). 저는 영어 원어민은 아니지만 pin "고정 해제"가 조금 ... 이상하다고 생각합니다.

@ crlf0710 그러나 특성이 가능하게하는 것은 핀에서 <moving> 아니라 <moving out of a Pin> 입니다. move의 문제와 move의 동의어는 특성이 유형의 이동 능력을 전혀 제어하지 않는다는 것을 암시한다는 것입니다. Pin과의 연결은 특성이 실제로 무엇을하는지 이해하는 데 중요합니다.

따라서이 특성에 대한 가장 관용적 인 이름은 "고정에서 벗어나 다"를 의미하는 동사 일 것입니다. "고정 해제"라는 단어가 제게 가장 분명한 단어입니다. 위키 낱말 사전의 "고정 해제"정의는 다음과 같습니다.

1. 핀을 제거하여 풀기.
2. (전이, 컴퓨팅, 그래픽 사용자 인터페이스) 이전에 고정 된 위치에서 분리 (아이콘, 응용 프로그램 등).

@withoutboats 설명해 주셔서 감사합니다! 사실 저는이 Unpin 이름이나 Rust 팀이 마침내 결정한 이름을 받아 들일 수 있다고 생각합니다. 저는 Pin 유형의 안정화를 전혀 차단하고 싶지 않으며 "이동"등에 대한 우려를 절대적으로 이해합니다.

어딘가에 아주 약간의 "반복"이 있다는 느낌이 듭니다. 그리고 나는 내 자신을 설득해야합니다. 그것은 "고정 불가능"을 의미하는 것이 아니라 그 반대입니다. 그것이 최종 결정이라면 얼마 후에 익숙해 질 것 같습니다.

동시에 제가 마지막 제안을 할 수있게 해주세요 : 사실 저는 위에서 언급 한 Detach 동사가 너무 일반적이지만 꽤 괜찮다고 생각합니다. 내가 말했듯이, 나는 원어민이 아니기 때문에 다른 사람들을 대변 할 수 없습니다. 그냥 작은 아이디어로 봐주세요.

나는 안전한 분리형 고정 돌출부에 대해 생각하고 있었고 그것을 가능하게 할 아이디어를 생각해 냈습니다. 고정 된 가변 lvalue에 대한 일치를 시뮬레이션하는 매크로 입니다. 이 매크로를 사용하여

pin_proj! { let MyStruct { field1, field2 } = a_pinned_mutable_reference; }

Pin<&mut MyStruct> 를 필드에 대한 고정 된 가변 참조로 분해합니다.

이를 안전하고 유용하게 만들려면 다른 두 가지가 필요합니다.

• "always- Unpin "필드를 표시하는 Kite 유형
• Unpin 안전하지 않게 만들기

후자는 프로젝션의 안전을 위해 필요합니다. 이것이 없으면 "고정 된 프로젝션으로 Kite "를 안전하게 정의 할 수 있습니다. 이것은 실제로 잘못된 것입니다.

이를 염두에두고 다른 유용한 작업을 안전하게 할 수있는 여지를 남겨두기 위해 안정화 전에 Unpin 안전하지 않게 만들 것을 제안합니다.

그것의 보증 고정 위반 유형에 대해 그것의 수를 @qnighy Drop 하게 구현, Drop 에 동등하게 강력한를 Unpin . Unpin 안전하지 않게 만들면 추가 코드가 안전하지 않습니다. Drop 도 안전하고 변경할 수 없기 때문입니다. 우리는 추적 문제에 대해 많이 이야기했으며이 스레드에서도 언급했습니다.

근본적으로, 오늘날 Rust에서 표현할 수없는 특정 음의 경계를 주장하는 능력 없이는 핀 투영을 안전하게 만들 수 없습니다.

뿡뿡

동시에 제가 마지막 제안을 할 수있게 해주세요. 사실 저는 위에서 언급 한 Detach 동사가 너무 일반적이지만 꽤 괜찮다고 생각합니다. 내가 말했듯이, 나는 원어민이 아니기 때문에 다른 사람들을 대변 할 수 없습니다. 그냥 작은 아이디어로 봐주세요.

Detach는 Move 및 Relocate와 같은 이름보다 훨씬 나아 보이지만, 분리 은유의 다른 가능한 사용과 충돌하는 것 같습니다 (Escape가 "탈출 분석"등과 충돌 할 수있는 방법과 유사 함). 데이터가 컴퓨터 과학에서 다른 데이터와 어떻게 관련 될 수 있는지에 대한 은유가 너무나 많기 때문에 Unpin의 또 다른 새로운 이점을 생각하게됩니다. "고정"은유를 단단히 쪼개면 미래의 은유 적 언어를위한 공간을 차지하지 않습니다. Detach, Escape 또는 Relocate와 같은 다른 목적으로 사용해야 할 수도 있습니다.

@withoutboats 나는이 Detach 다른 목적은 무엇입니까 (추론한다면 ...)?

@Centril 나는 명확한 사용 사례를 염두에 두지 않지만 예를 들어

@withoutboats 맞아요. 건배!

@withoutboats 나는하지 있는지 확인 위키 낱말 사전 항목의 이름 정당화하는 가장 좋은 동기 부여의 경우 해요 Unpin 사용하려면 move from a pin . 물리적 표현 은유는 Rust로 이동하는 것이 세계의 대상을 제거하지 않는다는 사실로 인해 어려움을 겪습니다. 더 정확하게 말하면, 고정 된 포인터를 'upinning'하면 참조 된 메모리를 제어 할 수 없습니다. T 의 개체 표현으로 할당 및 유효성이 여전히 필요하며 포인터 의미 체계에 의해 보장됩니다. 따라서 고정 해제는 unboxing처럼 T 의 완전히 제어 된 표현을 제공하지 않습니다. 그리고, 사전 항목이 정의 unpinning 측면에서 moving 더 같은 이름의 정당성보다 혼란의 사실 부분에 있습니다.

제안 된 API에서 어떤 방법도 그러한 효과가 없습니다 (핀의 범위에도 포함되지 않음). 예를 들어 Pin<Box<T>> 에서 Box<T> (및 T 로 확장)로 전환하는 안전한 방법이 없으며 Unpin 이 강력한 가능성이 있습니다. 모든 차이가 어디인지 정확히 모르겠습니다. 그러나 내가 이해하는 한, Pin 는 일부 메모리 위치에 적용되는 반면 Unpin 는 T 표현에서 핀 보장에 의존하는 것이 없음을 보장합니다. 그러나 그것은 기억을 완전히 빼고 잊을 수있는 것과 같을까요? 나는 그렇게 생각하지 않는다. 좀 더 구체적인 예를 생각해 보겠습니다.

편집 : 더 구체적으로 T 이 Unpin 하더라도 해당 메모리가 할당 해제되기 전에 고정 된 메모리에서 호출되는 T::drop(&mut) 인스턴스에 의존 할 수 있습니까? 형식주의에서 알 수있는 한 대답은 '예'여야하지만 Unpin 라는 이름

편집 2 : Rc 사용하면 Pin<&T> 를 관찰 할 수 있지만 T: Unpin 경우 원래 메모리 위치에서 drop 호출되지 않습니다. 핀 외부에서 참조를 유지하면 핀이 삭제 된 후 Rc::try_unwrap 로 이동할 수 있습니다. https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=dec6f6c6d2c0903d87a4a9cefe50a0ca 기존 메커니즘을 통해 질문에 효과적으로 대답하지만 의도 한대로 작동합니까?

아마도 IgnorePin ? T 이 IgnorePin Pin<Box<T>> 를 &mut T 하여 Pin 의 존재를 본질적으로 무시할 수 있습니다 (AIUI는 Box 도 무시 함). IgnorePin 가 아니라고 생각하지만 그것이 무엇인지 잘 모르겠습니다. IgnorePin 는 허용되는 것을 설명하고 유형에 적용되는 제약 조건을 설명하지는 않지만 Unpin 도 마찬가지입니다.

@wmanley 나는 위의 일부 주석에서 ElidePin 매우 유사한 아이디어를 가지고 있었지만 그 당시에는 왜 그것이 더 정확하다고 느꼈는지 구체적으로 표현할 수 없었습니다. 하지만 '하나의 동사'가 Rust 마커 특성에 대한 스타일 가이드라는 점에 동의합니다. !ElidePin / !IgnorePin 형식으로 더 자연스러운 부정을 허용하더라도 최적은 아닙니다.

@withoutboats 후속 질문 : 핀이 기본 메모리 측면에서 지정된 것처럼 Pinned 가 ZST이기 때문에 ZST도 Unpin 수도 있고 아닐 수도 있습니다. 나는 직관적으로 그 메모리 표현이 공식적으로 무효화되지 않으므로 T::drop(&mut self) 호출 할 필요가 없다고 직관적으로 말할 것입니다. 예를 들어 유출 된 Box 에서 &mut 'static _ 메모리에서 핀을 만들 수있는 방법과 매우 유사합니다 Box 동시에, 그것은 모두 틀렸을 수 있으며 다른 해석이 어떻게 가능할 것인지를 봅니다. 이 설정은 문서에서 주목할 가치가 있다고 생각합니다.

T: !Unpin 를 사용하여 Pin<P<T>> 를 생성 한 다음 고정을 관찰 한 것이 없다고 보장되는 경우 즉시 값 고정을 해제하는 것이 안전합니까? 고정 된 값이 poll-like 메서드가 호출 된 후 이동되는 경우에만 정의되지 않은 동작입니까?

@HeroicKatora 불행히도, 제네릭으로 인해 !Unpin 가 될 수있는 유형에 대해 Drop 를 구현하는 것이 오늘 가능합니다. 예 :

struct S<T>(T); // `!Unpin` if `T: !Unpin`
impl<T> Drop for S<T> { ... }

@cramertj 감사합니다.

@cramertj 그래서 우리는 제네릭 경계에서 T: ?Unpin 기본 설정됩니까? Sized 와 같은 기존 유형에 대해 T: Unpin 를 기본값으로 설정하지 않는 또 다른 이유가 있습니까? 그것은 짜증나게 엄격한 몇 가지 인스턴스를 제공하지만 추가 자동 바인딩으로 인해 회귀가 발생할 수 있습니까?

@HeroicKatora 표준 라이브러리의 모든 유형과 Unpin 에 대해 전혀 신경 쓰지 않는 코드 묶음에 ?Unpin 경계를 뿌려야 합니다.

Drop +! Unpin 유형을 만드는 또 다른 방법으로 PhantomPinned 필드를 추가하는 것도 안전합니다.

T : 기존 유형에 대해 고정 해제를 기본값으로 설정하지 않은 또 다른 이유가 있습니까?

고정 해제는 보내기 및 동기화와 같은 자동 특성 일 뿐이며이 제안에는 새로운 언어 기능이 포함되지 않습니다. 따라서 자동 특성이 이미 정의되어있는 것과 동일한 의미를 갖습니다. 즉, 기본적으로 제네릭에 적용되지 않는다는 것입니다 (자동 특성이 아니라 컴파일러에 내장 된 특성 인 Sized와 달리).

고정 된 값이 poll-like 메서드가 호출 된 후 이동되는 경우에만 정의되지 않은 동작입니까?

여기서 우리는이 맥락에서 정의되지 않은 동작이 실제로 전통적인 UB 유형이 아니라는 점을 분명히해야합니다. 오히려 해당 코드는 Pin의 유형을 관찰하여 해당 값의 소유권 의미론에 대해 가정 할 수 있습니다 (즉, Unpin을 구현하지 않으면 소멸자가 실행될 때까지 다시 이동되거나 무효화되지 않습니다). 컴파일러가 결코 발생하지 않는다고 가정한다는 의미에서 UB가 아닙니다 (컴파일러는 Pin이 무엇인지 모릅니다).

그렇습니다. 귀하가 제공 한 보증에 의존하는 코드가 없음을 확인할 수 있다는 의미입니다. 그러나 코드가 유형이 고정 된 것을 관찰 할 수 없기 때문에 당신이 한 일은 확실히 무의미합니다.

@cramertj 나는 조금 불행 할 것입니다. 사양에있는 Drop 와의 Pin 상호 작용에 약간 불편하지만 언어에는 없습니다. 인터페이스 정확성, 유용성 및 가까운 장래에 출시하는 것 사이에 상당히 상충됩니다. 위의 편집 2에 대한 설명을 얻을 수 있습니까?

Rc를 사용하면 Pin <& T>를 관찰 할 수 있지만 T의 경우 Unpin은 원래 메모리 위치에서 드롭이 호출되지 않습니다. 핀 외부에서 참조를 활성 상태로 유지 한 다음 핀이 삭제 된 후 Rc :: try_unwrap으로 이동할 수 있습니다. https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=dec6f6c6d2c0903d87a4a9cefe50a0ca

@HeroicKatora 코드의 문제는 Mem<'a>: Unpin 이지만 사용하는 안전하지 않은 코드 줄은 Unpin 구현하지 않는 유형에만 적용되는 가정에 의존합니다. 그 증거 포함하도록 요점을 편집 한 Mem<'a>: Unpin : https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=201d1ae382f590be8c5cac13af279aff를

Pin::new 를 호출 할 때 Unpin 바운드에 의존하며, 대상이 Unpin을 구현하는 포인터에서만 호출 할 수 있습니다.

당신이 발견했다고 생각한 허점을 고려했기 때문에 Rc<T: ?Unpin> 에서 Pin<Rc<T>> 로 갈 수있는 방법이 없습니다. Rc::pinned 핀에 Rc를 구성해야합니다.

@withoutboats 그냥 확인을 받고 싶었습니다. T: Unpin 실제로 무효화되기 전에 drop 호출을 옵트 아웃합니다. 그것은 질문을 구걸합니다.

fn into_inner(Pin<P>) -> P where P: Deref, P::Target: Unpin;

인터페이스의 어떤 부분도 보호하지 않기 때문에 Pin<Box<T>> 를 Box<T> 로 풀면 잠재적으로 유용합니다 (물론 T: Unpin 의 경우).

@HeroicKatora 그 기능이 안전하다는 것이 맞습니다. 추가해도 괜찮지 만이 스레드는 이미 수백 개의 주석이 있기 때문에 현재 안정화중인 API를 확장하지 않으려 고합니다. 모든 표준 API와 마찬가지로 필요에 따라 나중에 언제든지 추가 할 수 있습니다.

Unpin 의 이름 지정과 기능 모두 converse 메서드를 사용 하면 훨씬 더 이해하기 쉽습니다. 그리고 Pin 보장이 실제로 T: !Unpin 제한된다는 것을 알고 있습니다. 그것은 가능성을 보여주기 위해 탈출 해치를 만드는 대신 그러한 방법의 존재에 의해 직접적으로 입증 될 것입니다. : smile :. 그리고 그 문서는 제한 사항을 설명 (또는 한 번 더 연결)하기에 완벽한 장소가 될 것입니다. (하나는 심지어 그것을 명명하는 것이 좋습니다 unpin 대신 into_inner ).

편집 : 대부분 이미 존재하는 것을 일반화합니다.

impl<P> Pin<P> where P: Deref, P::Target: Unpin

• fn unpin(self) -> P

P=&'a mut T 대한 인스턴스화가 있으며 이는 제안 된

impl<'a, T: ?Sized> Pin<&'a mut T> where T: Unpin

• fn get_mut(self) -> &'a mut T

이제 안정화가 완료되었으므로 PFCP의 요점은 문제가있는 것 같습니다.

@rfcbot 취소

https://github.com/rust-lang/rust/issues/55766#issuecomment-437374982 에서 시작하여 개발 된 댓글이 문서로 변환되도록 추적하는 기능이 있나요? 베타가 분리 되었기 때문에 우리는 이미 출시에 너무 늦은 것 같습니다 ...

아직 열려있는 이유가 있습니까? @Centril 당신이 이것을 닫았다가 다시 열었습니다.

@RalfJung FCP를 취소하려고했지만 듣지 않았습니다. @alexcrichton FCP를 취소 할 수 있습니까?

이것은 안정적이므로 닫힙니다.