이제 스택 고정이 RFC의 일부가 아니라는 것을 알았습니다. @withoutboats 는이를 위해 크레이트를 출시 할 계획입니까? 아니면 예제 코드를 필요한 내 크레이트에 복사해야합니까?

@ Nemo157 당신은 그것을 복사하고 당신의 경험을보고해야합니다!

Unpin 데이터 유출에 대한 미해결 질문은 이것과 관련이 있습니다. @cramertj가 요청 Unpin 데이터를 Pin 덮어 쓸 수 없다고 말하면 해당 API는 불건전합니다. 이를 위해 작동하는 다른 덜 인체 공학적 스택 고정 API가 있습니다. 여기에서 올바른 선택이 무엇인지 불분명합니다. 인체 공학적 스택 고정 API가 더 유용합니까 아니면 누출에 대한 추가 보장이 더 유용합니까?

내가 주목할 한 가지는 루프에서 폴링 할 수 없었기 때문에 await! 매크로 내부의 Future::poll 와 같은 것에 스택 고정이 충분하지 않다는 것입니다. 나는 당신이 그 문제에 부딪히면 관심이 있고, 당신이 문제를 해결하는 방법 / 만약에 관심이 있습니다.

내 현재 사용은 지원을 생성하지 않고 단일 StableFuture 를 실행하는 단일 스레드 실행 프로그램으로 매우 사소 @cramertj 같은 API로 전환하면 제안 이와 함께 벌금을 작동합니다. 여러 StableFuture 생성 할 수 있도록이를 확장하는 방법이 궁금했지만 적어도 현재 프로젝트에서는 필요하지 않습니다.

API로 실험 해 보았습니다. Future 의 다음 (RFC에서 제안) 정의가 더 이상 객체로부터 안전하지 않은 것 같습니다.

trait Future {
    type Item;
    type Error;

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

신경 쓰지 마. arbitrary_self_types 개체 안전을위한 계획에 대한 메모를 찾았습니다.

안녕하세요.

한 가지 주목할 점은 스택 고정이 Future :: poll in the await와 같은 것에 충분하지 않다는 것입니다! 매크로는 루프에서 폴링 할 수 없었기 때문입니다.

그것에 대해 자세히 설명해 주시겠습니까?

@RalfJung 당신은 필요 Pin 지원과 같이 reborrows Pin 가 현재하지 않습니다.

@cramertj 스택 고정 API가 아닌 Pin API의 제한처럼 들리나요?

@RalfJung 네, 맞습니다. 그러나 PinBox 는 Pin 로 재차 용할 수 있지만 스택 고정 유형은 할 수 없습니다 ( Pin 로 빌리는 하나는 스택 유형의 전체 수명 동안 빌림을 생성합니다).

Pin 주어지면 &mut Pin 로 빌린 다음 Pin::borrow 를 사용할 수 있습니다. 이것은 재 차입의 한 형태입니다. 나는 당신이 말하는 종류의 reborowing이 아니라고 생각합니까?

같은 @RalfJung 말아요 - 방법 Future::poll 취할 계획되었다 self: Pin<Self> 보다는를, self: &mut Pin<Self> 유효하지 않은 ( self 'ISN 그것 때문에 유형 t Deref<item = Self> - Deref<Item = Pin<Self>> ).

실제로 Pin::borrow 과 함께 작동하도록 할 수있는 경우 일 수 있습니다. 잘 모르겠습니다.

@cramertj 나는 poll 에 x: &mut Pin<Self> poll 에 전화하도록 제안하지 않았습니다; x.borrow().poll() .

@RalfJung 오,

약간 어색하지만이 작업의 예가 있습니다.

다음 주에 Pin s로 수행하는 작업의 예를 게시하려고 노력하고 기억할 것입니다. 재 차입이 완벽하게 작동한다고 말할 수 있습니다. 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
    }
}

방금 impl<'a, R> Read for Pin<'a R> where R: Read + 'a 값을 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> {} 를 추가하는 것이 안전하다고 생각합니다.

우려 사항 : libstd의 대부분의 유형이 Unpin 유형 매개 변수가 Pin 가 아니더라도 무조건 Unpin 를 구현하기를 원할 것 같습니다. 예 Vec , VecDeque , Box , Cell , RefCell , Mutex , RwLock , Rc , Arc . 대부분의 상자는 고정에 대해 전혀 생각하지 않으므로 모든 필드가 Unpin 경우 유형이 Unpin Unpin 있습니다. 이는 건전한 선택이지만 불필요하게 약한 인터페이스로 이어집니다.

모든 libstd 포인터 유형 (아마도 원시 포인터를 포함 할 수도 있음) 및 UnsafeCell 대해 Unpin 를 구현하면이 문제가 저절로 해결됩니까? 그게 우리가하고 싶은 일입니까?

모든 libstd 포인터 유형 (아마도 원시 포인터를 포함 할 수도 있음) 및 UnsafeCell에 대해 Unpin을 구현하면이 문제가 해결됩니까? 그게 우리가하고 싶은 일입니까?

네, 저에게는 Send 와 같은 상황 인 것 같습니다.

새로운 질문이 방금 발생했습니다. Pin 및 PinBox Send 언제입니까? 지금, 자동 특성 메커니즘이 그들에게 수 Send 할 때마다 T 있다 Send . 그렇게 할 선험적 인 이유가 없습니다. 공유 유형 상태의 유형이 전송 가능성에 대한 자체 마커 트레이 트 ( Sync 라고 함)를 갖는 것처럼 Pin<T> 이 Send 인 경우를 나타내는 마커 트레이 트를 만들 수 있습니다. 예 : PinSend . 원칙적으로 Send 아닌 PinSend 하거나 그 반대의 경우도 가능합니다.

@RalfJung Pin 는 &mut T 가 Send PinBox 는 Box<T> 가 Send 일 때 Send입니다. 나는 그들이 다를 이유가 없다고 생각합니다.

음, 일부 유형이 Send 이지만 Sync 아닌 것처럼 "이 메서드가 Pin<Self> 로 호출되면 절대 이동되지 않음에 의존 할 수 있습니다. 다른 스레드로 ". 예를 들어, 이것은 처음 시작되기 전에 보낼 수 있지만 한 스레드에 남아 있어야하는 선물을 발생시킬 수 있습니다 (시작하기 전에 이동할 수 있지만 고정 된 상태로 유지해야하는 것과 유사). 설득력있는 예를 생각해 낼 수 있을지 모르겠습니다. 스레드 로컬 저장소를 사용하는 미래에 대한 것일까 요?

방금 @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,
        }
    }
}

(트랜스 뮤트를 사용하여 수명을 연장하는 방법을 사용할 수는 있지만, 그렇게하면 너무 멍청하게 느껴집니다).

해결되지 않은 질문을 추가하고 싶습니다. 공유 고정 참조 유형을 다시 추가해야합니까? 대답은 '예'라고 생각합니다. 자세한 내용 은 토론과 함께이

나는 방금 Futures 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 A를 한 종류의 Pin 불필요 수명을 단축하지 않고 필드 중 하나.

map 메서드의 또 다른 문제는 구조체의 Pin 를 구조체의 각기 다른 필드 인 두 개의 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 의 문서 주석은 현재 다음과 같습니다.

반환하는 데이터는 인수 값이 이동하지 않는 한 (예 : 해당 값의 필드 중 하나이기 때문에) 이동하지 않으며 수신 한 인수에서 벗어나지 않도록해야합니다. 내부 기능.

"반환하는 데이터는 인수 값이 이동하지 않는 한 이동하지 않는다"는 보장은 map 의 호출자가 유지해야하는 계약에 대한 올바른 설명입니다. 괄호 "(예를 들어, 해당 값의 필드 중 하나이기 때문에)"는 자신의 비공개 필드에 대한 참조를 반환하는 한 안전함을 보장한다는 것을 의미하는 것 같습니다. 하지만 Drop 를 구현하면 사실이 아닙니다. Drop impl은 다른 코드에서 이미 Pin<Self> 본 경우에도 &mut self 보게됩니다. mem::replace 또는 mem::swap 를 계속 사용하여 필드 밖으로 이동하여 map 의 이전 "올바른"사용에 의해 만들어진 약속을 위반할 수 있습니다.

즉, Pin::map 대한 "올바른 핀 프로젝션"호출을 사용하면 unsafe 의 다른 호출없이 Pin::map (호출은 unsafe { Pin::map(&mut self, |x| &mut x.p) } 와 유사 함)를 사용할 수 있습니다. 행동. 이것을 보여주는 놀이터 링크가 있습니다.

이것은 현재 API에 문제가 있음을 의미하지 않습니다. Pin::map 이 이미있는 unsafe 로 표시되어야한다는 것을 보여줍니다. 또한 미래를 구현할 때 사람들이 실수로이 문제에 걸려 넘어 질 위험이 많지 않다고 생각합니다. Drop impl에서 자신의 분야에서 벗어나기 위해 정말 자신의 길에서 벗어나야합니다. 그렇게하고 싶은 실질적인 이유가 많지 않을까.

그러나 나는 map 대한 문서 주석이 이것을 언급하고 싶을 것이라고 생각하며, RFC 및 주변 토론에서 볼 수있는 확장에 대한 몇 가지 아이디어를 무효화한다고 생각합니다.

• 매크로가 안 / 그 "핀 투사"를 수행하고 안전하게 보이게 유도. 프로젝션은 실제로 그것을 둘러싼 다른 코드에 계약을 부과하므로 컴파일러가 완전히 시행 할 수 없습니다. 따라서 완료 될 때마다 unsafe 키워드를 사용해야합니다.
• RFC는 Pin 가 &'a pin T 언어 기능으로 바뀌면 "필드를 통해 투영하는 것이 사소한"것이라고 언급합니다. 나는 이것이 개인 필드를 프로젝션하는 것으로 제한 되더라도 여전히 unsafe 이 필요하다는 것을 보여 주었다고 생각합니다.

안녕하세요.

핀이라도& T는 안전하게 & T로 캐스트 될 수 있습니다..

사실 그것은 충분한 조건이 아닙니다. 이전 게시물 에서 다음 정의를 만들었 기 때문에 내 모델에서 동일합니다.

정의 5 : PinBox<T>.shr . ptr이 T.shr('a, inner_ptr) 와 같은 다른 포인터 inner_ptr에 대한 읽기 전용 포인터 인 경우 포인터 ptr 및 수명 'a는 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 또는 계약의 결과가 아닙니다. 소유, 공유, 고정의 세 가지 유형 상태 만있는 모델의 결과입니다. &&T = &Pin<T> 에 대해 논쟁하고 싶다면 네 번째 유형 상태 인 "공유 고정"을 도입해야한다고 주장해야합니다.

안녕하세요.

핀에 대한 많은 논의에서 핀을 비공개 필드에 "투영"하는 것이 안전하다고 생각해야한다는 가정이있는 것 같습니다. 나는 그것이 사실이라고 생각하지 않습니다.

그것은 아주 좋은 지적입니다! 명확하게 말하면 Shenanigans 의 p 필드를 공개하는 데 문제가 없습니다. 이 시점에서 모든 클라이언트는 do_something_that_needs_pinning 를 작성할 수 있으며 RFC의 의도는이를 안전하게 만드는 것입니다. (저는 RFC가 왜 비공개 필드를 구체적으로 언급하는지 모르겠습니다. 내 해석은 항상 모든 필드에서 작동해야한다는 것이 었습니다.)

이것이 내 모델에서 drop 의 drop(ptr) 에 T.pin(ptr) 의 전제 조건이 있다고 썼습니다. 이 해석을 사용하면 예제의 실제 코드는 drop 구현입니다! 나는 우리가 결국 필드 안전한 전망을 허용 할 것 같아요 (포스트를 작성할 때 이미이 통지를하지 않았는지 지금은 ... 궁금), 우리는 정말 제공하지 않아야 drop 과 &mut 유형이 고정되는 경우

우리는 하나의 (a) 만들 수있는 방법이 impl Drop 안전하지 않은 유형 인 경우 !Unpin , 또는 (b)에 자사의 서명을 변경 drop(self: Pin<Self>) 의 경우 T: !Unpin ? 둘 다 극도로 억지로 들리지만 반면에 둘 다 Drop::drop 를 항상 Pin<Self> 를 사용하도록 변경할 수 있다면;) 물론이 시점에서 이것은 더 이상 라이브러리 전용 솔루션이 아닙니다. 슬픈 부분은 우리가있는 그대로 안정되면 결코 안전한 현장 투영을 할 수 없다는 것입니다.

@RalfJung 그래서 나는 실용적인 질문에 더 관심이 있습니다 (아마 기대했던 것처럼 : wink :). 두 가지가 있다고 생각합니다.

• Pin<T: !Unpin> Deref<Target =T> 구현해야합니까?
• Pin<T> 및 PinMut<T> (전자는 공유 핀)이 모두 있어야합니까?

첫 번째 질문에 부정적으로 대답 할 이유가 없습니다. 나는 당신이 두 번째 질문을 다시 열었습니다 생각; 나는 두 가지 다른 종류의 핀으로 돌아가고 싶다 (그러나 완전히 확신하지는 못함). 이것을 언어 수준 참조 유형으로 업그레이드하면 &pin T 및 &pin mut T 있습니다.

우리가 무엇을하든 모델은 API 불변을 정확하게 반영하기 위해 네 번째 유형 상태가 필요할 것 같습니다. &&T 를 &Pin<T> 로 변환하는 것이 안전해야한다고 생각하지 않습니다.

그래서 나는 실용적인 질문에 더 관심이 있습니다 (아마 윙크를 기대 하겠지만).

그럴 수 있지. ;) 그러나 안전하지 않은 코드가 그림에 들어 오면 Pin 주변에서 보장되는 것과 보장되지 않는 것에 대해 최소한 기본적인 이해를하는 것이 중요하다고 생각합니다. Basic Rust는이를 파악하기 위해 몇 년 동안 안정화되었습니다. 이제 우리는 몇 달 동안 Pin 동안 이것을 반복하고 있습니다. Pin 는 구문에 관한 한 라이브러리 전용 추가이지만 모델에 관한 한 중요한 추가입니다. 안전하지 않은 코드가 무엇인지 가능한 한 철저히 문서화하고 Pin 주위에서 가정하거나 수행하는 것이 허용되지 않는 것이 현명하다고 생각합니다.

이러한 우려는 현재 이론적이지만, 안전하지 않은 코드로 인해 호환되지 않는 가정을 만들어 첫 번째 불건전 함이 발생하면 갑자기 매우 실용적 일 것입니다.

두 번째 질문에 대해 :

우리가 무엇을하든 모델은 API 불변을 정확하게 반영하기 위해 네 번째 유형 상태가 필요할 것 같습니다. && T를 & Pin으로 변환한다고 생각하지 않습니다.안전해야합니다.

그것이 내가 기대했던 것입니다.

우리는 보수적 싶은 경우에, 우리는 이름을 바꿀 수 Pin 에 PinMut 그러나 추가하지 PinShr (가능성이 호출 할 수 Pin 하지만 난 여기에 명확하게하려고 ) 지금, 그리고 선언 안전하지 않은 코드가 있다고 가정 할 수 &PinMut<T> 뭔가를 실제로 포인트를 고정합니다. 그런 다음 나중에 공유 고정 참조로 Pin 을 추가 할 수 있습니다.

@comex 가 PinShr 를 갖는 실질적인 이유를 제기했습니다. PinShr<'a, Struct> 에서 PinShr<'a, Field> 까지의 getter를 제공 할 수 있어야합니다. 작동하지 않는 공유 핀에 &PinMut 를 사용하면 그런 게터가 얼마나 필요할지 모르겠습니다.

첫 번째 질문에는 (a) 객체 안전 임의의 자체 유형에 대한 현재 계획, (b) 공유 참조에서 기존 API를 안전하게 사용할 수 있다는 강력한 주장이 있습니다. PinShr (또는 PinMut ).

&mut 및 PinMut 모두에서 작동 할 수있는 작업을 유사하게 제공 할 수있는 쉬운 방법이없는 것 같습니다. &mut 에서 작업하는 많은 코드가 mem::swap 을 (를) 사용할 의도가없는 경우입니다. (내가보기에 이것은 !DynSized 기반 솔루션 또는 이와 유사한 솔루션의 주요 이점이 될 것입니다. &mut 는 고정되거나 고정되지 않을 수있는 참조 유형으로 바뀝니다. Pin API의 또 다른 라이브러리 유형으로 이것을 가질 수 있지만, 우리가 이미 모든 &mut 메소드를 가지고 있다는 점을 감안할 때 다소 무의미합니다.)

&T 및 PinMut<T> 둘 다에 대해 "흥미로운"일을하려는 유형에 대한 가벼운 주장이 하나 있습니다. 그것은하기 어려울 것입니다. 모든 것이 가능하지는 않으며 매우 조심해야합니다. 그러나 나는 그것이 유리한 좋은 주장을 능가한다고 생각하지 않습니다.

이 경우 (예 : impl Deref ), PinShr<'a, T> 에는 &'a T (수명 유지)로 바꾸는 안전한 메서드가 함께 제공되어야합니다.

그리고 우리가 해결해야 할 또 다른 문제가 있습니다 : @MicahChalmer 가 위에서 알아 차린 것에 Pin::map 및 / 또는 drop 에 대한 규칙 . 두 가지 선택이 있습니다.

• 공개 필드에 대한 프로젝션과 함께 Pin::map 사용하는 것이 항상 안전하다고 선언하십시오 (비 참조 없음, 암시 적이 지 않음). 이것은 현재 RFC에 대한 나의 해석입니다. 이는 &mut 및 & 와 일치합니다. 그러나 Drop 주위에 문제가 있습니다. 이제 제대로 구성된 !Unpin 유형이 주어지면 UB를 발생시키는 안전한 코드를 작성할 수 있습니다.
• Drop 주위에서 재미있는 일을하지 마십시오. 그런 다음 Pin::map 에 공공 장소에 사용해도 불건전해질 수 있다는 큰 경고를 추가해야합니다. &pin T 가 있더라도이를 사용하여 안전한 코드의 필드에 액세스 할 수 없습니다.

내가 볼 수있는 두 번째 옵션에 대한 유일한 가능한 주장은 우리가 실제로 구현할 수있는 유일한 옵션 일 수 있다는 것입니다. ;) 가능한 모든면에서 열등하다고 생각합니다. 언젠가는 내장되어 있어도 &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 와의 유일한 차이점은 전출 부분에 안전한 코드 만 포함되어 있다는 것입니다. Drop impl에 관계없이 해당 필드를 벗어나면 안전 하지 않다는 점을 지적하기 위해 Pin::map 메모를 변경해야하는 것 같습니다.

경우에 따라 !Unpin 유형의 필드 밖으로 이동하는 것이 안전해야합니다. 생성자가 돌아올 때 해당 필드 중 하나에서 이동할 가능성이 높기 때문입니다.

Drop impl에서 필드를 벗어나면 해당 필드의 핀을 다른 곳으로 투영하는 것이 불건전하다는 것을 문서화하는 것이 좋습니다.

이것은 두 번째 옵션으로, &pin 필드에 영구적으로 안전하지 않은 작업을 만드는 옵션입니다.
나는 이것이 작은 변화가 아니라고 생각합니다. 이것은 필드에서 pub 의미를 근본적으로 변경합니다. 라이브러리 유형을 사용할 때 드롭 impl에서 수행하는 작업을 알 수 없으므로 기본적으로 해당 필드에 대한 고정 참조를 얻을 수있는 방법이 없습니다.

예를 들어, Option 가 Drop 가 아무것도하지 않을 것이라고 명시 적으로 명시하지 않는 한 Pin<Option<T>> 에서 Option<Pin<T>> 로 이동할 수 없습니다. " 이상한". 컴파일러는이 명령문을 이해할 수 없으므로 Option 는이를 수행하는 적절한 방법을 제공 할 수 있지만 match 동일한 작업을 수행하는 것은 안전하지 않은 작업으로 유지되어야합니다.

Drop과의 유일한 차이점은 이사하는 부분에 안전한 코드 만 포함되어 있다는 것입니다.

그러나 그것은 큰 차이가 있지 않습니까? 안전하지 않은 코드가 무엇을 할 수 있는지 여부에 대해 임의의 규칙을 설정할 수 있지만 안전한 코드에는 그렇지 않습니다.

생성기가 돌아올 때 필드 중 하나에서 이동할 가능성이 매우 높기 때문에 경우에 따라! Unpin 유형의 필드 밖으로 이동하는 것이 안전해야합니다.

이 경우 필드는 Unpin ? 따라서 해당 필드의 유형이 Unpin 경우 외부 구조체의 공용 필드에 대해 Pin::mut 라는 규칙이있을 수 있습니다. 이것이 얼마나 유용한지는 확실하지 않지만 아무것도없는 것보다 낫습니다.

&&T 보다 더 많은 보증을 제공하지 않는 &Pin<T> 에 대한 혼란을 재빨리 다시 말씀 드리고 싶습니다. & , &mut 및 &pin 각각 "공유 액세스", "고유 액세스"및 "이동되지 않는 값에 대한 고유 액세스"를 제공합니다. &&pin 를 "이동되지 않는 유형에 대한 고유 액세스에 대한 공유 액세스"로 이해하면 메모리가 공유된다는 것을 알 수 있습니다 ( &pin 의 고유성 보장은 & ),하지만 유형이 이동되지 않는 속성은 여전히 ​​유지됩니다.

나는 당신이 무엇을 요구하거나 말하는지 잘 모르겠습니다. "공유 고정"이 그 자체로 기본 모드 / 유형 상태라고 생각하는 이유를 헷갈 리 시나요?

요점은 "공유 액세스"는 내가 스스로 정의하는 방법을 아는 것이 아니라는 것입니다. 예를 들어 Cell , RefCell 및 Mutex 공유하는 매우 다양한 방법에서 알 수 있듯이 공유를 공유하고 조정하는 방법에는 여러 가지가 있습니다.

당신은 당신이 소유 한 것을 공유한다고 말하고 (어떤 것의 "유일성 보장을 취소하는") 그 진술이 의미가있을 것이라고 기대할 수 없습니다. 공유하는 방법과 이것이 혼란을 야기하지 않도록 보장하는 방법을 말해야 합니다 . "읽기 전용으로 공유"또는 "동기화 된로드 / 스토어를 통한 원자 적 액세스 만 제공하여 공유"또는 "이 차용 플래그가 배포 할 액세스 종류를 조정하여 [단 하나의 스레드 내에서] 공유"할 수 있습니다. . RustBelt의 핵심 포인트 중 하나는 모든 유형이 공유 될 때 발생하는 일을 스스로 정의하도록하는 것의 중요성을 깨달았습니다.

공유 및 고정의 직교 구성으로 "공유 고정"을 발생시키는 방법을 생각할 수 없습니다. 아마도 "(정상) 공유"와 "고정 공유"를 발생시키기 위해 소유 된 또는 고정 된 불변에 적용될 수있는 "공유 메커니즘"의 개념을 정의하는 방법이있을 수 있지만, 나는 그것을 심각하게 의심합니다. 또한 RefCell 대해 평평하게 떨어지는 것을 보았 듯이- RefCell 가 공유 고정 고정 고정에 대해 수행하는 것과 유사한 일을 공유 고정 고정에 대해 수행하는 경우 & &pin RefCell<T> 에서 정당화 할 수 없습니다. &RefCell<T> ( Deref ) borrow_mut 를 통해 고정이 발생하지 않았다는 &mut 참조를 얻을 수 있습니다.

뿡뿡

드롭에 고정 해제 바인딩을 추가하고 바인딩이없고 드롭이 핀을받는 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 무조건.

& mut 및 PinMut에서 모두 작동 할 수있는 작업을 유사하게 제공 할 수있는 쉬운 방법이없는 것 같습니다. & mut에서 작업하는 모든 코드가 mem::swap 을 (를) 사용할 의도가없는 경우.

PinMut 에 DerefMut impl가 있으면 문제가 해결됩니다. 고정에 관심이 있고 PinMut 필요한 코드는 &mut 에서 작동하는 코드를 안전하고 쉽게 호출 할 수 있습니다. 대신 mem::swap 를 사용하려는 일반 함수에 부담이 가해질 것입니다 .-- 그들은 Unpin 바운드를 추가하거나 unsafe 하고주의를 기울여야합니다. 핀 조건을 위반하지 마십시오.

이러한 경계를 swap 및 replace 에 추가하면 첫 번째 안정적인 릴리스로 돌아가는 이전 버전과의 호환성이 깨집니다. 여기에서 거기에 도착하는 현실적인 방법이 보이지 않습니다. 하지만 1.0 일 이전에 이것이 알려졌다면해야 할 일이되었을 것이라고 생각하는 다른 구멍을 놓치고 있습니까?

현재 @withoutboats가 말한 것보다 더 좋은 해결책은 없습니다. map 안전하지 않게 유지하고 이전에 drop 에 고정 된 필드에서 벗어나지 말라고 경고하는 메시지를 문서에 넣습니다.

안전하지 않은 코드가 무엇을 할 수 있는지 여부에 대해 임의의 규칙을 설정할 수 있지만 안전한 코드에는 그렇지 않습니다.

unsafe 사용하면 항상 주변 안전 코드에 규칙이 적용됩니다. 여기서 좋은 소식은 우리가 아는 한, 고정 가능한 구조체가 개인 필드에 핀을 투사하는 방법을 가지고 있다면 자신의 drop impl만이이를 사용하여 안전한 코드에서 계약을 위반할 수 있다는 것입니다. 따라서 이러한 프로젝션을 추가하고 해당 구조체의 _users_에게 완전히 안전한 API를 제공하는 것은 여전히 ​​가능합니다.

Drop의 정의가 정말로 여기서 문제입니까?

비난을 할당하는 것은 다소 임의적이며 건전성 구멍을 막기 위해 변경할 수있는 여러 가지가 있습니다. 하지만 제가 제안한대로 Drop 를 변경하면 문제가 해결된다는 데 동의합니까?

그것에 대해 생각하는 또 다른 방법은 mem :: swap 및 mem :: replace에 대한 비난을 두는 것입니다. 소유하지 않은 것을 이동할 수있는 작업입니다. T : Unpin bound가 추가되었다고 가정합니다.

그러면 &mut T 일반적으로 !Unpin 유형에 사용하기에 안전합니다. 보시다시피 PinMut 도 더 이상 필요하지 않습니다. 제안서의 PinMut<'a, T> 는 &'a mut T 로 정의 될 수 있습니다.
이것은 본질적으로 이전 버전과의 호환성 및 언어 복잡성 문제로 인해 폐기 된 ?Move 제안입니다.

안전하지 않음을 사용하면 항상 주변 안전 코드에 규칙이 적용됩니다.

무슨 말인지 잘 모르겠습니다. 프라이버시 경계를 넘어서서는 안됩니다. 안전하지 않은 코드는 클라이언트에 어떤 것도 부과 할 수 없습니다.

여기서 좋은 소식은 우리가 아는 한, 고정 가능한 구조체가 개인 필드에 핀을 투사하는 방법을 가지고 있다면 자체 드롭 impl만이이를 사용하여 안전한 코드의 계약을 위반할 수 있다는 것입니다. 따라서 이러한 프로젝션을 추가하고 해당 구조체의 사용자에게 완전히 안전한 API를 제공하는 것은 여전히 ​​가능합니다.

예, 유형은 프로젝션을 안전하게 선언하도록 선택할 수 있습니다. 그러나 예를 들어 차용 검사기는 이것이 필드 액세스라는 것을 이해하지 못하므로 PinMut<Struct> 주어지면 이러한 방법을 사용하여 두 개의 다른 필드에 동시에 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 loan_and_move_and_borrow_again () {
let mut x = X;
take_a_mut_ref (& mut x);
let mut b = Box :: new (x);
take_a_mut_ref (& mut * b);
}
````

PinMut<'a, T> 에서 &'a mut T 로 이동하는 것이 안전하지만 그 반대는 아닙니다. PinMut::new_unchecked 은 (는) 여전히 존재하고 unsafe 입니다.

이것은 본질적으로 이전 버전과의 호환성 및 언어 복잡성 문제로 인해 폐기 된 ?Move 제안입니다.

내가 알고있는 것처럼, ?Move 제안이 필요하지 않도록 모든 방법을 얻으려고 노력했다 PinMut 함으로써 (위의 코드를 금지, 기본적인 언어 규칙을 변경하여 Unpin 는 Move 특성이됩니다.) 저는 그런 것을 제안하지 않습니다. 제 제안은 지금 밤마다 정확히 시작하는 것입니다.

• std::mem::swap 및 std::mem::replace 함수에 바인딩 된 Unpin 추가
• 제거 Unpin 으로부터 구속 DerefMut IMPL의 Pin ( PinMut 그 이름 변경이 발생하는 경우)

그게 다입니다. 움직임이 작동하는 방식에 대한 근본적인 언어 변경은 없습니다. 내 주장은 다음과 같습니다. 예, 이것은 브레이킹 체인지이지만 Drop ( ?Move 제안보다 여전히 덜 과감 함)를 변경하는 것보다 깨지는 영향이 적고 혜택의. 특히 안전한 핀 프로젝션을 허용하고 (적어도 개인 필드에 대해서는, 공개적으로도 확실하지 않습니까?) PinMut 및 &mut 와 함께 작동하도록 병렬 코드를 작성해야하는 상황을 방지합니다.

아니요, PinMut < 'a, T>는 여전히 대상이 다시는 움직이지 않을 것이라고 약속해야합니다. & 'a mut T를 사용하면 평생 움직이지 않는다는 것만 믿을 수 있습니다.

내가 참조. 말이된다.

내가 이해하는대로? Move 제안은 위의 코드 스 니펫을 금지하도록 기본 언어 규칙을 변경하여 (Unpin을 Move 특성으로 만들어) PinMut을 필요로하지 않는 모든 방법을 시도했습니다.

알겠습니다.

내 주장은 : 예, 이것은 브레이킹 체인지이지만 드롭을 변경하는 것보다 브레이킹 영향이 적습니다.

드롭 할 변경은 무엇입니까? 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 문서를 추가하더라도 기존 코드를 선물 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 특성을 사용하도록 코드를 업데이트하지 않으면 실제로 !Unpin 유형을 사용하는 것이 매우 어려울 수 있습니다 (따라서 생태계는 모든 것을 thew new version),하지만 !Unpin 를 전혀 사용하지 않은 코드를 깨뜨리지 않고 건전성을 유지하기 때문에 괜찮을 것이라고 생각합니다. 또한 "라이브러리가 업그레이드되지 않으면 코드 패닉"이 발생하면 사람들이 앞으로 나아가도록 장려 할 것입니다!

사실, 제가 제안한 디자인은 다음과 같습니다.

Pin을 사용하는 두 번째 방법으로 Drop 특성 확장, 제안한대로. 특수한 기본 구현 where T: Unpin 호출 드롭 (현재 전문화 ​​규칙을 통과 할 것이라고 가정합니까?하지만 그렇지 않더라도 Drop 은 항상 특수한 경우가 될 수 있습니다. 또한 Drop 함수는 일반적으로 자동 생성됨). 이제 이전 버전과의 호환성 문제가없고 경계를 어색하게 자동 파생하려는 시도없이 위에서 제안한 것과 똑같은 동작이 있습니다.

써드 파티 라이브러리가 !Unpin 유형에서 실질적으로 유용하도록 업그레이드해야한다는 문제가 있지만, 제가 말했듯이 이것은 틀림없이 좋은 것입니다. 어쨌든, 얼마나 많은 drop 구현이 실제로 &mut 를 요구하는 방식으로 필드를 변경하는지 알지 못합니다-제가 생각할 수있는 대부분은 unsafe 또는 내부 변경 가능성을 사용하지만 일반적인 사용 사례는 생각하지 않을 것입니다.

이 접근 방식의 가장 중요한 점은 Pin 가 안정화되기 전에 취해야한다는 것입니다. 이것이 제가 정말로 Pin 이 (가) 서두르지 않기를 바라고있는 또 하나의 이유입니다. 저는 우리가 디자인 결과를 충분히 탐구하지 않았다고 생각합니다.

(I는 참조 할 또 하나의 잠재적 인 문제 : ManuallyDrop 누군가가 아마도 가정 않은 제네릭 형식을 통해 소멸자를 작성했습니다 수 있다는 일반적으로 평균 노동 조합 drop 그 안에서 구현 당황하지 수를 그것은 실행할 수 결코 간단하기 때문에 (또한 다른 호출 할 수 없습니다 것입니다 &mut 당황하지 않겠다고 약속하는 것이 안전하지 않은 특성에 구현 사람을 제외하고, 일반 T에 기능). 이후 Pin 유형은 이미 메모리가 소멸되기 전에 드롭 구현이 실행되도록 보장해야합니다 [새로운 의미 체계에 따라]. 저는 ManuallyDrop 에서 해당 용도로 사용되는 !Unpin 유형을 믿습니다. 기존 코드에서 처음부터 고정 된 것으로 간주 될 수 없으므로 기존 코드가 해당 가정을하는 경우 여전히 정확해야합니다. 확실히, ManuallyDrop 에 안전하게 핀을 투영 할 수 없어야합니다. 드롭 전에 소멸자가 호출되도록 보장하는 경우에만 안전 할 수 있습니다.이 케이스를 comp에 어떻게 전달할지 모르겠습니다. 이것은 유사한 목적을 위해 의도 된 것처럼 보이므로 "eyepatch"를 전혀 활용할 수 있습니까?]. 나는 그것이 의미 론적으로 날아가는지는 잘 모르겠지만 아마도 기존 코드에 대한 Drop 구현의 목적으로 작동 할 것입니다.

아이 패치의 주제에 관해서는 ... 아직 정확한 공식적인 정의는 확실하지 않지만, T에서 흥미로운 일반 함수가 호출되지 않는다는 일반적인 생각이 있다면, 더 많이 활용할 수 있을까요? 즉, !Unpin 유형에 대한 drop_pinned 구현이 구현 된 경우 아이 패치 관련 컨테이너가 올바르게 작동합니다. 한 후 컴파일 시간 오류 수에 대해 나에게 가능한 것 !Unpin 구현 유형 Drop , 구현하지 않는 drop_pinned 에, 그들의 일반적인 매개 변수를 안대하지 않습니다 자기 참조 수명이있는 비안 대 컨테이너를 사용할 때와 같은 방식입니다.

실존성은 모든 컴파일 타임 전략에 심각한 하위 호환성 위험을 초래합니다. 그래서 런타임에 실패하는 솔루션이 더 현실적이라고 생각합니다. 이것은 런타임 오류가없고 오 탐지도 없을 것입니다.

편집 : 우리는 정말 소멸자에서 액세스 할 필드,하지에 대해 걱정할 필요가 : 사실, 위의 모든 스크래치 &mut 일반적 접근, 수정을? &mut self 암시 적 필드 프로젝션에 대해서만 걱정하기 때문입니다.

나는 단지 !DynSized 제안을 재창조하고 있을지도 모르지만, 본질적으로 : 제네릭 컨테이너가 핀 유형 상태를 신경 쓰는 메소드를 노출한다면 이미 !Unpin 가되어야합니다 (이것이 잘못된 매개 변수처럼 들린다는 것을 알고 있습니다. 논쟁, 그러나 내 말을 들어라!). Box<Trait> 및 &mut Trait Box<Trait> 와 같은 기존 항목이 반드시 Unpin 상태를 반영하지는 않지만 (적어도 현재 API를 쳐다 보면?) Pin<Box<T>> 라고 생각하지 않습니다. Pin<&mut T> 반드시 Pin<T> 로 강제 변환되어야합니다. 여기서 T: !Unpin ; 구현하지 않으면 이러한 유형에 대한 고정 된 참조가 내부에 대한 고정 된 액세스를 안전하게 제공하지 못함을 의미합니다 (& mut 및 &의 관계와 관련하여 이에 대한 몇 가지 전례가 있음에 유의하십시오. & mut & T는 & mut T에 대해 강요 할 수 없으며 & T 만 가능합니다. Box <& mut T>는 Box<T> 강제 할 수 없으며 일반적으로 & mut T; 만 다른 유형 상태가 충돌 할 때 자동으로 전파 될 필요가 없습니다. 일반적으로 &mut T , Box<T> 및 T 은 유형 상태 관점에서 완전히 상호 교환 가능한 것으로 간주되며이 인수는 가상의 인라인 실존성까지 확장되지 않지만 아마도 이것은 DynSize 제안의 내용 (안전 스왑을 허용하지 않거나 특성 개체 값에 대해 mem::replace s를 허용하지 않습니까? 실제로는 이미 허용되지 않았습니다 ...하지만 다음이 있다고 가정합니다. 이것이 미래에 변경 될 수있는 이유). 이는 컴파일 시간 솔루션을 매우 간단하게 만듭니다. (전 이적으로) 직접 소유하는 (& mut, &, Box 또는 원시 포인터 없음) Pin 액세스를 안전하게 전 이적으로 전파하지 않는 구조의 경우 , 공유 핀의 경우 & 를 제외하고 & 은 (는) 어쨌든 이동할 수 없습니다. 또는 "ca n't move out of trait objects"솔루션을 사용하기로 결정한 경우 또한 &mut 및 Box 따라 전 이적으로 필드를 확인할 수 있고 (가시성 측면에서) 알려진 !Unpin 유형 (자체 포함)에 액세스 할 수 있습니다. drop 의 두 번째 종류를 구현합니다. 안정된 유형이 !Unpin 아니기 때문에 완전히 괜찮은 것 같고 이전 버전과의 호환성이 전혀없는 것 같습니다. 사람들은 라이브러리를 업데이트 한 후 소멸자를 다시 구현해야 할 수도 있지만 그게 다예요? 또한 내부 구현 세부 사항은 내부적으로 유지됩니다. !Unpin 필드가 노출 된 경우에만 문제가 발생합니다. 마지막으로 모든 일반 컨테이너 유형 ( Vec 및 표준 라이브러리 항목뿐만 아니라 기본적으로 전체 crates.io 생태계)은 계속해서 잘 작동합니다. 이 솔루션에 대해 내가 놓친 재앙적인 점은 무엇입니까?

(사실, drop 정의 시간에 이것을 시행 할 수 없더라도 적어도 dropck 처럼 유형 인스턴스화 시간에 그렇게 할 수 있어야한다고 생각합니다. 완전히 인스턴스화 된 유형에 대해서만 걱정할 필요가 있기 때문에).

Dynsized 제안을 다시 읽음 : 고정 된 경우에도 고정 유형이 항상 DynSized 이어야한다는 주장에 반대하는 주장이있었습니다. 나는 위에서 우리가 특성 객체의 경우에만 이것에 대해 걱정할 필요가 있다고 주장합니다. !Unpin 유형을 + ?DynSized (또는 자동으로 수행 될 수 있음)로 명시 적으로 제한해야하는 특성에 대해 !Unpin 유형을 강제 적용하는 것이 가능할 수 있습니다 (정확히 설명하기는 어렵지만). 물론 크기가 알려져해야 많은 경우가있을 수 있지만 !Unpin 유형 (실제로, 나는! 이러한 유스 케이스가), 또는 그들이가 고정되기 전에, 나는 거기에 희망을 교환 할 수 있어야합니다 움직일 수없는 유형으로 만들어진 특성 개체의 내부에 대한 그러한 경우는 거의 없습니다 (현재 우리가 가지고있는 유일한 경우는 명시 적으로 금지하려는 Box -> Rc 변환과 같은 경우입니다. 맞습니까? size_of_val 가 노출되는 것이 실제로 문제인지 아닌지는 저에게도 분명하지 않습니다. Pin<'a, Box<Trait> 를 Pin<'a, Trait> 로 바꿀 수 있을지 아직 알 수 없기 때문입니다. Sized 에 의존 할 수 있습니다.) 어떤 경우에도 !Unpin 로 묶을 수 있기를 원하지만 제가 말했듯이 사람들은 우리가 이미 필요로하는 것보다 더 많은 부정적인 특성을 추가하지 않기를 원한다고 생각합니다 (개인적으로는 !Unpin 트레이 트 객체는 Unpin 가 아닌 ?Unpin 가진 경계 트레이 트 객체가 완전히 합리적이고 유형 시스템을 너무 많이 감염시키지 않을 정도로 충분히 희귀하고 전문화 될 것입니다. 대부분의 용도는 !Unpin 일반적으로 Pin<self> 에 대한 작업을 수행하기를 원하기 때문에 대부분의 기존 특성에 대한 유용한 구현이 없을 것이라고 생각할 수 있습니다. 일반적으로 PinBox 와 함께 사용하고 싶을 것입니다. 또는 PinTypedArena 또는 ?Unpin 경계가 매우 자연스럽게 보이는 지점).

나는 새로운 디자인을 가지고 있는데, 이것은 이전 디자인만큼 끔찍하지 않다고 생각합니다 : https://github.com/pythonesque/pintrusive/blob/master/src/main.rs. 핀 프로젝션이 모든 곳에서 작동하도록하는 대신이 디자인은 항상 고정을 지원하고자하는 "최신"Rust 코드에서 고정에 대해 아무것도 모르는 "레거시"Rust 코드와 상호 운용 할 수있는 방법을 묻습니다. 분명한 대답은 @RalfJung이 제안한 PinDrop 특성을 사용하는 것으로 보이지만 둘 다 사용자 지정 드롭이 있고 필드를 투영하려는 유형에만 해당됩니다.

유형은 "현대"Rust로 작성된 코드와 유사한 프로젝 팅 필드 ( PinFields 특성 파생에 해당)를 명시 적으로 선택합니다. 그러나 "레거시"Rust의 코드에 대한 추가 요구 사항은 없으며, 대신 PinFields 의 주어진 파생물에 대해 깊이 1 로의 투영 만 지원하도록 선택합니다. 또한 참조를 통해 Pin 을 (를) 이동하려고 시도하지 않습니다. 어쨌든 그렇게하지 않는 것이 좋은 생각이라고 생각합니다. 그것은 동일한 필드와 변형을 가진 구조를 생성함으로써 Rust가 제공 할 수있는 모든 분리 분석을 포함한 구조와 열거를 지원하지만, 유형에 대한 Pin 'd 참조로 대체 된 유형 (사소해야합니다) 변경시 Pin 및 PinMut 로 확장). 분명히 이것은 이상적이지는 않지만 (최적화 프로그램이 대부분을 제거 할 수 있기를 바라지 만), 차입 및 NLL과 함께 작동하고 열거 형으로 쉽게 작동한다는 이점이 있습니다 (생성 된 접근 자와 반대).

안전 주장은 Drop이 구조에 대해 전혀 구현되지 않았는지 확인하거나 Drop이 구현 된 경우 PinDrop (Pin을 사용하는 Drop 버전) 만 호출하는 사소한 구현인지 확인하여 작동합니다.). 나는 이것이 하나의 물음표와 함께 고정 된 필드를 투영하는 모든 건전성 문제를 배제한다고 믿습니다. 내 주요 관심사는 서로를 무효화 할 수있는 정확히 동일한 컨테이너 (즉, 깊이 1의 필드)에서 분리 된 필드에 대한 좋은 주장을 찾는 것입니다. 소멸자의 핀은 핀 투영 없이는 이미 유효하지 않습니다. 별도의 PinBox에 보관 된 경우에도 동일한 작업을 수행 할 수 있음을 보여줄 수 있다면이를 정당화 할 수 있습니다. 이는 그들이 사는 곳 이 안전 계약의 일부임을 의미합니다. 즉, 소멸자는 격리 상태에서 안전하지 않으며 모듈 외부에서 구성하려면 안전하지 않은 코드가 필요합니다. 다시 말해서, 그것들의 정확성은 컨테이너 유형의 구현에 달려 있습니다. 즉, 임의의 안전한 코드를 요구하는 것보다 소멸자에게 더 많은 것을 요청해도 괜찮습니다.

@pythonesque 나는 DynSize 에 대해 위에서 쓴 것을 실제로 따르지 않았지만 어쨌든 지금은 구식이라고 생각합니까? 그래서, 나는 당신의 최근 게시물에 대해서만 댓글을 달 것입니다.

요약하면, 구조체 / 열거 형 ( pub 필드 포함)의 필드에 프로젝션하는 것은 일반적으로 안전하지 않지만 유형은 Drop 구현하지 않음 으로써 안전한 필드 프로젝션에 옵트 인 할 수 Drop . 유형이 소멸자를 원하면 PinDrop 대신 Drop .

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

우리는 이미에 대한 유형 체킹 모습이 Drop 가도를 확인하기 위해 비현실적인하지 않는 것, 그래서 필드의 이사 거부를 Drop 스루 투사 거부 &pin . 물론, PinDrop 이 있으면 "moving out of field"확인은 여전히 ​​거부되지만이 경우 프로젝션은 허용됩니다.

컴파일러는 Drop 적용되는 것과 동일한 제한을 PinDrop 에 적용하고 유형이 Drop 및 PinDrop 모두 구현하지 않도록합니다. 드롭 글루를 생성 할 때 유형이 구현 한 모든 종류의 Drop 를 호출합니다.

그것이 제안을 요약합니까? 제가 이해하지 못하는 부분은 마지막 단락입니다. 걱정되는 부분을 보여주는 예를 들어 주시겠습니까?

당연히 여기에 증명 의무가 무엇인지 궁금합니다. 나는 이것을 보는 가장 쉬운 방법은 PinDrop 가 실제로는 공식적으로 존재하는 주된 유일한 소멸자이고, impl Drop for T 는 실제로 impl PinDrop 대한 구문 설탕이라고 말하는 것입니다. 안전하지 않은 메서드 PinMut::get_mut 호출 한 다음 Drop::drop 호출합니다. 이것은 자동 생성 된 안전하지 않은 코드 이지만 고정은 "로컬 확장"(즉, 기존의 안전하지 않은 코드와 역 호환 됨)이기 때문에 해당 유형이 고정에 관심이없는 경우 안전하지 않은 코드는 항상 안전합니다.

좀 더 공식적으로 말하자면, 작성자가 고정에 관심이없는 경우 유형이 갖는 "기본 고정 고정"이 있습니다. 기본 고정 고정을 사용하는 유형은 자동으로 Unpin 입니다. 사용자 정의 불변이있는 유형에 대해 impl Drop 를 작성하면 해당 유형이 "기본 고정 불변"을 사용한다고 주장합니다. 여기에 증명 의무가있는 것처럼 느껴지므로 약간 비린내이지만 이에 대해 경고 할 unsafe 가 없습니다. 실제로 이것은 완벽하지는 않지만 이전 버전과의 호환성이 중요하므로 무엇을 할 수 있습니까? 하다. 이것이 실제로 의미하는 바는 다른 곳에서 안전하지 않은 코드에서 발생하는 증명 의무를 변경하여이 안전하지 않은 코드가 "기본 고정 불변"과 함께 작동해야한다는 점을 주장 할 수 있기 때문에 재앙이 아닙니다. 이 모듈의 다른 곳에 안전하지 않은 코드가 없으면 모든 것이 정상입니다.

난 우리가에 보풀을 추가 할 수 있다는 것을 상상할 수 impl Drop for T 하지 않는 한 T: Unpin , 어쩌면 유형을 정의하는 모듈이 그것에서 안전하지 않은 코드가있는 경우로 제한. 사람들에게 문제에 대해 교육하고 unsafe impl Unpin (공식적으로 기본 고정 불변을 사용한다고 주장함)을 권장하거나 impl PinDrop 를 권장합니다.

뿡뿡

그것이 제안을 요약합니까?

예, 다소간 (Drop이 구현되지 않은 경우 자동으로 프로젝션을 수행하는 것을 제안하는 것처럼 보이므로 귀하의 제안은 실제로 내 것보다 훨씬 더 야심 찬 것 같습니다. 이는 아마도 라이브러리의 포워드 호환성 문제라고 생각합니다. 그).

제가 이해하지 못하는 부분은 마지막 단락입니다. 걱정되는 부분을 보여주는 예를 들어 주시겠습니까?

대체로 말하자면, 동일한 구조에 직접 사는 두 개의 필드에 대해 걱정하고 있는데, 그중 하나는 Drop이 호출 될 때 다른 하나를 변경하여 (안전을 위해 Drop Order와 같은 것에 의존하여) 고정 불변을 위반하는 방식으로 다른 필드는 구조적 무결성을 유지합니다 (따라서 고정 불변의 위반을 목격 할 수 있음). 이것은 분명히 완전히 안전한 코드를 사용할 수 없기 때문에 (그렇지 않으면 다른 무엇보다도 dropck에 의해 거부 될 것입니다), 내 관심사는 필드가 개별적으로 고정 될 때 필드 유형의 소멸자가 실행하기에 안전한 일부 가상의 경우에 관한 것입니다. 구조이지만 동일한 구조에 고정되어 있으면 안전하지 않습니다. 내 희망은 필드가 포함 된 구조를 포함하는 공유 불변이 없으면 그러한 경우가 없다는 것입니다. 그러한 불변성이있는 경우 해당 구성 요소가 사용자 정의 불변을 적절하게 존중하지 않는다는 것을 인식해야하며 따라서 모듈의 어딘가에서 코드를 비난 할 수 있습니다.

나는 이것을 보는 가장 쉬운 방법은 PinDrop이 실제로 공식적으로 존재하는 주된 유일한 소멸자이며 T에 대한 impl Drop은 실제로 안전하지 않은 메서드 PinMut :: get_mut을 호출하고 호출하는 impl PinDrop의 구문 설탕이라고 말하는 것입니다. Drop :: drop.

동의합니다. 안타깝게도이 방법은 라이브러리에서 작업을 시도하기 때문에 현재 솔루션에 개방되지 않았습니다.

좀 더 공식적으로 말하자면, 작성자가 고정에 관심이없는 경우 유형이 갖는 "기본 고정 고정"이 있습니다. 기본 고정 고정을 사용하는 유형은 자동으로 고정 해제됩니다. 사용자 정의 불변이있는 유형에 대해 impl Drop을 작성하면 유형이 "기본 고정 불변"을 사용한다고 주장합니다. 여기에 증명 의무가있는 것처럼 느껴지기 때문에 약간 비린내이지만 이에 대해 경고하는 것이 안전하지 않습니다. 실제로 이것은 완벽하지는 않지만 이전 버전과의 호환성이 중요하므로 무엇을 할 수 있습니까?

예, 이것은 대략 제가 염두에두고있는 것입니다 ... 저는이 "모듈의 안전하지 않은 코드"보장을 실제로 공식화하는 것이 무엇을 의미하는지에 대한 좋은 직관이없는 것이 걱정됩니다. 나는 당신의 보푸라기 아이디어가 마음에 들지만 (사실, PinDrop을 사용하는 사람들이 더 많은 것을 좋아합니다!)하지만 unsafe impl Unpin 가 제안하기에 좋은 제안이 되기에는 너무 자주 틀렸을 것입니다. 최소한 일반 공용 필드가있는 유형의 경우 (하지만 다시 말하지만 이러한 필드가없는 구조의 경우 실제로 매우 자주 사실입니다 ... 예를 들어 표준 라이브러리에 대해 대체로 사실입니다).

#[derive(PinnedFields)] 작동 방식에 대한 예제를 작성했습니다 : https://github.com/withoutboats/derive_pinned

나는 사람들이 이와 같은 파생물이 "건전하지 않다"고 주장하는 것을 보았지만 사실이 아니다. 이 파생물에 의해 생성 된 코드와 충돌하는 작업을 수행하려면 안전하지 않은 코드를 사용해야합니다. 즉, 이로 인해 다른 안전하지 않은 코드가 건전하지 않게됩니다 (그리고 ?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 의해 스스로를 가져 가야 한다는 것입니다! 보다 급진적 인 (아마도 획기적인) 변화를 만드는 것은 매력적으로 보이지만 크게 파괴되지 않는 방식은 보이지 않습니다.

고정 된 필드 + 드롭으로 인해 발생할 수있는 불건전 한 액세스의 예는 다음과 같습니다. https://play.rust-lang.org/?gist=8e17d664a5285e941fe1565ce0eca1ea&version=nightly&mode=debug

Foo 유형은 명시 적으로 링크가 해제 될 때까지 버퍼가있는 위치에 머물도록 요구하는 일종의 외부 API에 내부 버퍼를 전달합니다. 내가 아는 한 @cramertj가 제안한 제약 조건 하에서 이것이 소리가 나는 한 Pin<Foo> 가 생성 된 후에는 Drop 가 호출 될 때까지 이동되지 않는다는 것을 보장합니다. 대신 유출 될 수 있고 Drop 는 절대 호출되지 않지만이 경우 절대 이동되지 않을 것이라는 보장이 있습니다.)

Bar 유형은 Drop 구현 중에 Foo 를 이동하여이를 중단합니다.

DMA를 통해 통신하는 무선 주변 장치를 지원하기 위해 Foo 와 매우 유사한 구조를 사용하고 있습니다. 무선 장치에 의해 작성된 내부 버퍼가있는 StableStream 을 (를) 가질 수 있습니다.

안녕하세요.

이게 옳은 거니?

예, 실제로 no-op Drop impl을 생성하지 않는다는 점을 제외하면 (Rust에서 Drop 를 구현하지 않는 유형이 일반적으로 더 잘 작동하기 때문입니다). 대신 Drop 가 일부 비린내 라이브러리 기능을 사용하여 구현되지 않았다고 주장하려고합니다 (안정적으로 작동하지만 전문화에서 중단됨-전문화에서 작동 해야 하지만 지금 합니다. 관련 상수와 관련된 문제). 그것이 언어 기능으로 만들어 졌다면 이것을 시행하는 것은 매우 쉬울 것입니다.

나는 또한이 모든 것이 우리가 침입적인 컬렉션을 지원하기 위해 Pin의 보증을 연장 한 경우에만 중요하다고 생각합니다. 이것이 @ralfj 및 @pythonesque에 대한 이해와 일치합니까?

아니요, 안타깝게도 그렇지 않습니다. 위에 링크 된 반례는 침입 컬렉션에 대한 추가 보장과 관련이 없습니다. Pin 'd 유형은 고정 된 참조 뒤에서 값에 대해 메서드가 두 번 호출되면 값이 다음과 같기 때문에 해당 보장 없이도 다시 사용되기 전에 이동하지 않을 것이라고 가정 할 수 있어야합니다. 두 통화간에 이동했는지 알 방법이 없습니다. 침입 컬렉션에 유용하게 만드는 데 필요한 추가 보장은 메모리가 해제되기 전에 drop 를 호출해야한다는 추가 사항을 추가하지만, 보장하지 않아도 drop 는 여전히 무언가에 대해 호출 될 PinBox 에있는 필드 값), 그런 다음 이전에 고정되었을 때 참조가 계속 유효 할 것으로 예상하는 메서드를 호출합니다. 나는 그 주위에 어떤 방법도 보지 못한다. drop 구현할 수있는 한 모든 인라인 !Unpin 필드에 대해이 문제가 발생할 수 있습니다. 그렇기 때문에 사람들이 제대로 작동하도록 고정하려면 drop 구현하지 않는 것이 가장 나쁜 해결책이라고 생각합니다.

이 모든 것이 다소 실망 스럽습니다. 왜냐하면 Drop은 Pin이 스스로를 가져 가야한다는 것이 분명해 보이기 때문입니다! 보다 급진적 인 (아마도 획기적인) 변화를 만드는 것은 매력적으로 보이지만 크게 파괴되지 않는 방식은 보이지 않습니다.

네, 정말 짜증이나요 ... 일주일 동안 너무 졸 렸어요. 그러나 Ralf가 지적했듯이, 우리는 누군가 이것을 알아 내기 전에 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 값을하고 그 위에 고정 된 메소드를 호출 . 안전하지 않은 것이 필요하지 않습니다. 이 고정 된 필드를 투영 할 수있는없이 문제가 아니다 유일한 이유는 실제로 이상한 구현하는 유형에 대해 허용 간주한다는 것입니다 !Unpin 사용 방법 unsafe (또는 주 않는 유형 불변 ) 안전한 코드 만 사용하더라도 drop 구현에 대한 증명 의무가 있습니다. 그러나 !Unpin 유형을 포함 하고 자신의 안전하지 않은 코드가없는 유형에 대해서는 물어볼 수 없습니다.

안녕하세요.

Drop이 구현되지 않은 경우 자동으로 프로젝션을 수행 할 것을 제안하는 것처럼 보이므로 귀하의 제안은 실제로 내 것보다 훨씬 더 야심적이라고 생각합니다. 이는 아마도 라이브러리의 포워드 호환성 문제라고 생각합니다. 하지만 그 주위에 어떤 방법이있을 수 있습니다

우리는 결국 그렇게하고 싶다고 생각합니다. 어떻게 호환성 문제입니까?

나는 같은 구조에 직접 사는 두 개의 필드에 대해 걱정하고 있는데, 그중 하나는 다른 필드의 고정 불변을 위반하는 방식으로 Drop이 호출 될 때 다른 하나를 변경합니다 (안전을 위해 drop order와 같은 것에 의존 함). 그러나 구조적 무결성을 유지합니다 (따라서 고정 불변의 위반을 목격 할 수 있음).

그러나 그것은 현재 이미 불법입니다. 다른 사람의 불변성을 위반해서는 안됩니다.

하지만 안전하지 않은 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에서 내 의견을 참조하십시오). 현재는 전체 고정에 대해 더 확신을 가질 때까지 조금 기다려야한다고 생각하지만 실제로 포인터 간접 지정을 넘어서 고정을 적용하는 데는 거의 의미가 없습니다.
나는 원시 포인터에 대해 어떻게 생각하는지 잘 모르겠지만, 우리는 모든 종류의 미친 방식으로 사용되기 때문에 일반적으로 자동 특성에 대해 매우 보수적입니다.

안녕하세요.

# [derive (PinnedFields)]가 어떻게 작동하는지에 대한 예제를 작성했습니다 : https://github.com/withoutboats/derive_pinned

@pythonesque는 이미 이것을 말했지만 분명하게 @MicahChalmer 의 드롭 문제 와 함께 사용하면 실제로 고정에 의존하는 고정 유형을 깰 수 있습니다. 이것은 drop 호출에 대한 추가 보장과는 무관합니다. 여전히 예가 필요한지 알려주세요. ;)

뿡뿡

그 도서관은 불건전합니다.

명확히하기 위해 파생은 unsafe 이며 수동 Drop impl과 함께 사용할 수 없습니다. 파생을 사용하면 Drop 구현에 나열된 나쁜 일을하지 않겠다고 약속합니다.

https://github.com/rust-lang/rust/pull/50497 은 고정 API를 변경합니다. 가장 중요한 것은 공유 된 Pin 를 추가 할 공간을 만들기 위해 Pin 에서 PinMut 로 이름을 바꾼 것입니다. 앞으로 Pin .

명확히하기 위해 파생은 안전하지 않으며 수동 Drop impl과 함께 사용할 수 없습니다.

동의하면 안전하지 않게 만들면 작동합니다. 테스트에서 현재는 실제로 안전하지 않은 것으로 표시되지 않은 것처럼 보이지만?

@RalfJung 맞아, 지금은 아닌 것 같아. 내가 방금 생각한 또 다른 옵션은 "안전한"버전이 유형에 대해 Drop 구현을 생성하여 Drop 의 다른 수동 impls를 차단하는 것입니다. 이 기능을 끄려면 unsafe 플래그가있을 수 있습니다. 어떻게 생각하십니까?

@cramertj 그래도 작동해야합니다. 그러나 더 제한적인 dropck와 같은 부작용이 있고 필드 밖으로 이동할 수 없습니다.

@pythonesque 와 나는 월요일에 이것을 논의하기 위해 전화를 받았다. 여기에 요약이 있습니다.

우리는 아마도 "올바른"행동이 Drop 이 스스로를 핀으로 가져가는 것이라고 결론지었습니다. 그러나 그것으로 전환하는 것은 어렵습니다. 내가 믿는 어떤 형태로든 에디션 변경이 가능하지만 이것은 매우 파괴적 일 것입니다.

이전 버전과 호환되는 변경은 Drop 구현하기 위해 "고정 프로젝션"될 수있는 유형에 대해 어떻게 든 일관성이 없게 만드는 것입니다. 그의 저장소에서 @pythonesque 는 복잡한 특성 세트에서 impl을 생성하여이를 구현했습니다.

좀 더 간단한 내장 양식을 상상할 수 있습니다.

• 마커 트레이 트는 PinProjection 라고 부르며 유형을 고정 할 수 있는지 여부를 제어합니다. PinProjection 및 Drop 모두 구현하는 것은 (컴파일러 내장 매직을 통해) 일관성이 없습니다.
• 또 다른 특성 인 PinDrop 는 PinProjection 를 확장하여 Drop 대한 대체 소멸자를 제공합니다.

@pythonesque 와 같은 핀 프로젝션 메서드를 생성하기 위해 PinProjection impls도 생성됩니다.

안녕하세요.

우리는 아마도 "올바른"행동은 Drop이 스스로를 잡는 것이었을 것이라고 결론지었습니다. 그러나 그것으로 전환하는 것은 어렵습니다. 내가 믿는 어떤 형태로든 에디션 변경이 가능하지만 이것은 매우 파괴적 일 것입니다.

우리가 언젠가 그런 일을하고 싶다면 미래와 호환되는 것을 제안하는 것이 무엇인지 궁금합니다.

예를 들어, 우리가 결정했다고 가정 해 봅시다.

• Drop 고정 된 양식과 고정되지 않은 양식을 모두 마법처럼 받아들이도록하거나
• Rust 2021 로의 자동 업그레이드의 일환으로 모든 사람의 Drop 서명을 다시 작성합니다. :)

(나는 이들 중 하나를 제안하지 않지만 구체적인 예가 없으면 질문에 답하기가 어려워 보입니다.)

@tmandry 그것은 본질적으로 아이디어입니다.

큰 문제는 유형 매개 변수를 이동하는 일반적인 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 데이터를 이동하는 유효한 사용 사례를 알지 못하므로 기술적으로는 할 수 있지만 의도하지 않은이 경우는 정말 문제입니다.

안녕하세요.

또 다른 특성 인 PinDrop은 PinProjection을 확장하여 Drop에 대한 대체 소멸자를 제공합니다.

이유는 무엇입니까 PinDrop 확장 PinProjection ? 불필요한 것 같습니다.

또한 유형이 Unpin 가 아니면 PinProjection 와 Drop 가 호환 되지 않는다고 말함으로써 약간 더 현명하게 만들 수 있습니다 (또는 이러한 모든 새로운 구별 / 제한 사항을 제거하는 다른 방법을 찾음 Unpin 유형).

@RalfJung 우리는 PinDrop 와 Drop 가 어떻게 든 상호 배타적 이기를 원합니다. 궁극적으로이를 구현하는 몇 가지 방법이 있습니다. 작은 변화가 아니기 때문에 RFC가 필요하다고 생각합니다.

@withoutboats 동의합니다. 나는 독점 성이 PinDrop 의 특별한 대우에서 발생할 수 있다고 생각했지만 분명히 여러 가지 방법이 있습니다. Unpin 유형이 신경 쓸 필요가 없다면 매우 유용 할 것이라고 생각합니다. 모든 포인터 유형을 Unpin 무조건 만드는 것과 함께 이것은 아마도 사람들이 이것에 대해 알아야하는 경우의 수를 줄이는 데 도움이 될 것입니다.

@withoutboats 또한 사람들이 소멸자의 Vec 에서 일반 데이터를 이동하려는 위치를 생각할 수있는 주요 인스턴스에 주목할 가치가 있습니다 (IIRC 사람들이 원하기 때문에 Vec 선택했습니다. 메소드 구현 Vec 사실에 관심 있다고 Pin 가 무조건 구현하지 수있는 수단, Unpin , 그것은 사실입니다) &mut Vec<T> 또는 Vec<&mut T> 또는 뭔가. @RalfJung이 제안한 lint에 의해 아마도 넘어 질 수있는 사례이기 때문에 나는 주로 unsafe impl Unpin 대신 이러한 경우에 쉽게 PinDrop 로 이동할 수 있기를 바랍니다. (이론적으로 그들은 항상 T 를 유형에 Unpin 로 묶어 전자를 수행 할 수 있지만 이는 라이브러리의 클라이언트에 큰 변화가 될 것입니다).

또한 이것이 우리가 원하는 것보다 몇 가지 더 많은 특성을 추가하지만 특성은 거의 모든 유형의 서명에 나타나지 않을 것입니다. 특히 PinProjection 는 #[derive(PinFields)] 매크로를 작성하지 않는 한 완전히 무의미한 경계입니다. 컴파일러는 항상 PinProjection 가 가능한지 여부를 결정할 수 있기 때문입니다. 유형의 필드가 무엇인지 파악하면 필드를 프로젝션하는 데 유용합니다. 마찬가지로 PinDrop 는 기본적으로 어떤 것에 대한 바운드 일 필요가 없어야합니다. 같은 이유로 Drop 는 거의 바운드로 사용되지 않습니다. 트레이 트 객체조차도 거의 영향을받지 않아야합니다 (언젠가 "관련 필드"를 얻지 않는 한,하지만 이와 같은 새로운 기능을 사용하면 관련 필드가있는 트레이 트를 PinProjection 유형에서만 구현할 수 있으므로 깔끔하게 해결할 수 있습니다.) 그 문제).

뿡뿡

우리는 결국 그렇게하고 싶다고 생각합니다. 어떻게 호환성 문제입니까?

나는 그것이 Send 또는 Sync 구현을 해제하는 유형을 추가하는 것보다 더 많지 않다고 생각합니다. 차이점은 둘 다 핵심 언어에 영향을 미치지 않는다는 점입니다. 완전히 자동으로 수행하는 것은 Rust가 Copy 를 처리하는 데 사용 된 방식과 유사 해 보입니다 ( Copy 유형 만 포함하고 Drop 구현하지 않은 경우 유형은 항상 Copy 이었습니다. ) 이는 결국 명시 적으로 변경되었습니다. 아마도 사람들은 특성 ( Drop )을 추가 하면 인식하지 못한 채 제네릭 코드를 깨뜨릴 수 있다는 사실을 좋아하지 않았기 때문입니다 (일관성의 요점은 특성 구현은 다운 스트림 크레이트를 깨서는 안됩니다). 이것은 단지와 거의 동일한 것 PinProjection 대신 Copy . 나는 실제로 예전의 행동을 좋아했고, Copy 가 그렇지 않은 경우 PinProjection 이 이런 식으로 작동하는 것을 정당화하기 어려울 것이라고 생각합니다.

그러나 그것은 현재 이미 불법입니다. 다른 사람의 불변성을 위반해서는 안됩니다.

네, 더 많이 생각할수록 문제가 될 것 같지 않습니다.

대부분의 경우 실제로 정확할 것이라고 생각합니다.

예,하지만 대부분의 유형이 Pin 를 필요로하는 메소드를 구현하지 않거나 일반 필드를 공용으로 노출하지 않기 때문입니다. 후자는 변경 될 것 같지 않지만 전자는 그렇지 않습니다. 현재 !Unpin stdlib 유형 중 적어도 일부가 핀 프로젝션 메서드를 추가 할 것으로 예상합니다. 이때 unsafe 구현은 더 이상 유효하지 않습니다. 그래서 그것은 나에게 꽤 깨지기 쉬운 것 같습니다. 또한 사람들이 작성해야하는 안전하지 않은 "보일러 플레이트"코드의 양이 늘어나는 것이 걱정입니다. Send 및 Sync 경계는 잘못 구현 된만큼 자주 올바르게 unsafe impl 'd이며 Unpin 는 훨씬 더 교활합니다. 일반적으로 올바른 버전에는 T 에 대한 경계가 없습니다. 따라서 사람들을 PinDrop 유도하는 것이 훨씬 더 선호되는 것 같습니다 (하지만 원시 포인터 유형에 대해주의하는 이유는 이해합니다. 이미 unsafe 코드가 생각하지 않고 unsafe impl 를 할 가능성이 더 높지만, 생각하면할수록 원시 포인터의 기본값이 정확하고 보풀로 플래그를 지정하는 것이 유용 할 것 같습니다.)

Unpin 유형은 신경 쓸 필요가 없다면 매우 유용하다고 생각합니다.

나는 약간 동의하지만 사람들이 PinProjection 를 실제 범위로 사용하지 않을 것이라고 말했듯이 실제로 그것이 얼마나 중요한지 확신 할 수 없습니다. 이미있다 DerefMut 대한 구현 PinMut 경우 T: Unpin 오늘 그것을 어떤 혜택을 얻을 수 없겠죠 그래서. 컴파일러에서 구현 된 규칙 (프로젝션 용)은 아마도 PinMut::new 를 Unpin 유형에 대한 일종의 &pin 재차 용으로 바꿀 수 있지만 실제로는 필드 프로젝션과 관련이 없습니다. 그리고 PinProjection 파생하는 데 필드에 대해 PinProjection 가 필요하지 않으므로 다른 유형의 derive 에 대한 경계를 충족하기 위해 필요하지 않습니다. 그래서 정말로 이득은 무엇입니까? 실제로 할 수있는 유일한 것은 Drop 를 구현하고 동시에 PinProjections 를 파생하는 것입니다.하지만 가능하다면 항상 사람들이 PinDrop 를 구현하기를 원합니다. 순 네거티브 IMO 여야합니다.

IIRC 사람들이 실제로 Pin에 관심이있는 Vec 메서드를 구현하기를 원하기 때문에 Vec을 선택했습니다. 즉, Unpin을 무조건 구현할 수 없음을 의미합니다.

흠, 나는 그것을 좋아하지 않는 것 같아요. Box 이 무조건 Unpin 이면 Vec 이 동일해야한다고 생각합니다. 두 유형은 일반적으로 소유권이 거의 동일합니다.

또한 drop 보장에 대해주의해야합니다. 예를 들어 Vec::drain 는 패닉이 발생했을 때 정보가 유출 될 수 있습니다.

Copy 대신 PinProjection을 사용하면 거의 동일 해 보입니다.

오, 이제 당신의 질문을 이해했습니다. 제 제안에 이와 같은 특성이 없었기 때문에 실제로 PinProjections 자동 파생에 대해 이야기 한 것이 아닙니다. 그러나 실제로 제 제안의 결과 중 하나는 Drop 를 추가하는 것이 중요한 변경 사항이라는 것입니다. 공개 분야가 있습니다.

실제로 할 수있는 유일한 것은 Drop을 구현하고 동시에 PinProjections를 파생시키는 것입니다. 그러나 우리는 항상 사람들이 가능하다면 PinDrop을 구현하여 그것이 net negative IMO가되기를 바랍니다.

그게 사실 포인트였습니다. 사람들이이 모든 고정 장치에 대해 신경을 덜 쓸수록 좋습니다.

설명 질문 : 귀하와 @withoutboats 의 제안에서 PinDrop lang 항목이고 컴파일러에서 Drop 의 대체물로 처리하거나 derive(PinProjections) 사용하는 특성일까요? Drop 구현?

또한 드롭 보장에 대해주의해야합니다. 예를 들어 Vec :: drain은 패닉이 발생했을 때 정보가 유출 될 수 있습니다.

사실입니다.하지만 실제로 메모리 할당을 해제하지는 않습니다. 맞습니까? 명확하게 말하면, Vec 이 Unpin 무조건 구현하면 사람들이 PinDrop 쉽게 전환 할 수 있기 때문에 실제로 더 선호합니다. 백킹 요소에 고정하는 방법에 대한 고정 논의 중 일부입니다. 고정되는 필드 에 대해 이야기하기 시작하면 Vec 를 제자리에 Box<[T]> 로 바꾼 다음 고정 할 수는 없다는 사실이 분명해집니다. 그 지점 ( Box 에서했던 것처럼 Vec 유형 대신 PinVec 유형을 추가 할 수도 있음).

그게 사실 포인트였습니다. 사람들이이 모든 고정 장치에 대해 신경을 덜 쓸수록 좋습니다.

흠, 내 관점에서는 처음에는 사실이지만 장기적으로는 가능한 한 많은 사람들을 기본값 인 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 나는 단 하나의 주요 관심사가 있다고 생각하지만 꽤 중요한 문제입니다. RFC는 최종 &pin mut 유형이 언젠가 이러한 종류의 코드를 안전하게 만들 수 있다는 이해를 바탕으로 승인되었습니다.

struct Foo<T> { foo : T }

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

실제로 고정 된 참조는 안전한 코드에서 그렇지 않으면 실제로 구성 할 수 없기 때문에 이러한 종류의 코드가 안전해야합니다. 예를 들어 퓨처 조합을 구현하려면 unsafe 사용해야합니다. 당시에는 대부분의 경우 unsafe 이 해제 될 수 있다고 생각되었으므로 큰 문제는 아닐 것입니다.

안타깝게도 이것이 안전한지 여부는 Foo 에 대한 Drop 구현에 따라 다릅니다. 따라서 안전한 필드 프로젝션을 지원하려면 (언어 기능, 사용자 정의 #[derive] 또는 기타 메커니즘을 통해) 그러한 잘못된 Drop 구현이 가능하다는 것을 보장 할 수 있어야합니다. t 일어나.

가장 잘 작동하는 것으로 보이는 대안은 unsafe (구조 위에 #[derive(PinProjections)] 만 추가하면 됨)없이 위의 코드가 작동하도록하고 기존 코드를 손상시키지 않습니다. . Pin 이 이미 안정화 된 경우에도 하위 호환성을 추가 할 수 있으며 순수한 라이브러리로 추가 할 수도 있습니다 (심각한 인체 공학적 히트 포함). 접근자를 생성하는 #[derive] 매크로와 최종 &pin 네이티브 참조 유형 모두와 호환됩니다. 적어도 하나의 새 트레이 트를 추가해야하지만 ( Drop 의 고정 된 버전이 구현되는 방식에 따라 2 개 정도 가능) where 절이나 트레이 트 객체에 나타날 필요는 없습니다. drop 의 새 버전은 현재 Drop 구현이 있고 핀 프로젝션을 선택하려는 유형에 대해서만 구현하면됩니다.

솔루션이 단점이 많지 않은 것처럼 보인다고해서 실질적인 변화가 아니라는 의미는 아니므로이 제안에 대한 RFC를 거의 확실하게 생성 할 것이라고 생각합니다 ( @withoutboats 및 통화에서이 작업에 대해 논의했습니다). . 완전히 이전 버전과 호환되므로 격리하여 펀트하는 것이 좋습니다. 그러나 개인적으로 다른 곳에서 고정을 제거하는 것보다이 변경 사항을 적용하는 것이 더 합리적이라고 생각합니다.

공용 API에서 PinMut 에 대한 대부분의 사람들의 우려는 정확히 unsafe 또는 모든 곳에서 Unpin 경계를 통한 스레딩이 필요하다는 것이며,이 제안은이 문제를 해결합니다. rust-lang / rfcs # 2418에서 논의 된 대안은 고정 (공개 API 및 문서에 나타날 다양한 다른 특성의 확산을 포함)을 처리하지 않으려는 방식의 실제 메커니즘에서 훨씬 더 논쟁의 여지 가 있습니다. 솔루션의 전체적인 복잡성. 실제로 고정이 완전히 해결되었다고하더라도 사람들이 그 RFC로 적절하게 해결되었다고 생각하지 않는 질문이 많이 있다고 생각하므로 RFC가 안전한 핀 투영을 추가 할 가능성은 적어도 괜찮은 것 같습니다. 그 전에 받아 들여지고 있습니다.

고정이 초기 단계에있는 것은 사실이지만 (너무 빨리 안정화되는 것 같다고 불평했다는 것을 알고 있습니다), 안전한 필드 프로젝션의 부족이 사람들이 전혀 사용하지 못하게하는 마지막 주요 요인이라고 생각합니다. . 완전성을 위해 사람들이 고정을 통해 제기 한 모든 문제, 제안 된 솔루션 및 솔루션이 기존 Pin 유형과 하위 호환되는지 여부 (매우 거칠고 편향된 순서로 논란의 여지가 있음 나는 현재 문제라고 생각합니다) :

• 이것은 (안전한 코드로 프로젝 팅 필드를 만들 수 있습니까?). 다가오는 RFC에 의해 해결 될 것입니다 (가능한 구현 전략과 우리가 고려한 다른 대안 및 폐기해야하는 이유). 제안 된 해상도의 모든 변형은 이전 버전과 호환됩니다.

• 수동 소멸자를 사용하여 !Unpin 유형의 값을 고정하면 추가 보장 (소멸자가 호출 될 때까지 값의 백업 메모리가 무효화되지 않음), 일명 "침입 수집에 대한 변경"을 의미합니까?

  아직 해결되지 않았습니다. 대부분 제안 된 스택 고정 API가 손상 될 수 있기 때문입니다. 이 보증을 유지하는 스택 고정 API가 비동기로 작동하도록 만들 수 있다면 / 대부분의 이해 관계자가 이것을 기꺼이 받아들이는 것처럼 보입니다 (IIRC 누군가 이미 생성기를 사용하여이 문제를 해결하려고 시도했지만 rustc ICE'd).

  이전 보증과 역 호환되지 않습니다. 현재 보증을 시행하기 위해 안전하지 않은 코드를 요구하는 것은 가능한 두 결과 모두와 호환되지만 안전하지 않은 코드가 정확성을 위해 시행되는 것에 의존 할 수없는 경우에만 가능합니다. 따라서 고정이 안정화되기 전에 어떤 방법 으로든 해결해야합니다.

  다행히 Future s 고정 사용자는 스택 고정 API의 모양 외에이를 무시할 수 있습니다. 클로저 기반 스택 고정 API는 두 가지 해상도 중 하나와 호환되므로 async / await를 사용하지 않는 Future 사용자는 이것이 결정될 때까지 기다리지 않고 오늘 클로저 기반 API를 사용할 수 있습니다. 이 결정은 다른 목적 (예 : 침입 컬렉션)으로 고정을 사용하려는 사람들에게 가장 큰 영향을 미칩니다.

• 원시 포인터는 무조건 Unpin 이어야합니까? 아직 해결되지 않았습니다. (나는 그것을 제안한 유일한 사람이라고 생각하며 여전히 거의 50-50입니다.) 이전 버전과 호환되지 않습니다. 나는 주로 그 이유 때문에 이것을 논란의 여지로 표시하고 있습니다.
• Vec 와 같은 표준 라이브러리 유형을 무조건 Unpin 로 만들어야합니까, 아니면 Pin 필드 접근자를 추가해야합니까? 아직 해결되지 않았으며 사례별로 해결해야 할 수 있습니다. 주어진 안전한 래퍼 유형에 대해 접근자를 추가하거나 유형을 무조건 Unpin 로 만드는 것은 이전 버전과 호환됩니다.
• PinMut::deref 을 제거해야합니까? 대답은 기본적으로 "아니오"인 것 같습니다. 유지하는 이점이 단점보다 훨씬 큰 것 같고, 원래 사람들이 그것을 원하게 만든 사례 (특히 Pin<RefCell<T>> )에 대한 해결 방법이있는 것 같습니다. 변경하면 이전 버전과 호환되지 않습니다.
• 단기간에 필드 접근자를 어떻게 제공해야합니까 (드롭 문제 무시)? 아직 해결되지 않음 : 지금까지 제시된 두 가지 옵션은 https://github.com/withoutboats/derive_pinned 및 https://github.com/pythonesque/pintrusive입니다. 드롭이 변경된 후에는 순수하게 라이브러리 코드에서 매크로에서이 작업을 수행 할 수 있으므로 해상도는 이전 버전과 완전히 호환됩니다.
• 장기적으로 필드 접근자를 어떻게 제공해야합니까 (예 : 사용자 정의 &mut pin 및 &pin Rust 유형이 있어야합니까? 재차 용은 어떻게 작동해야합니까?). 아직 해결되지 않았지만 다른 모든 제안 된 변경 사항 (내가 아는 한)과 역 호환되며 무기한으로 펀팅 될 수 있습니다.
• 안전한 참조 유사 유형은 무조건 Unpin 이어야합니까? 해결 될 것 같습니다 (예, 그래야합니다). 해상도는 이전 버전과 완전히 호환됩니다.
• 필드 접근자를 실행 가능하게 만들기 위해 고유 한 Pin Pin 유형 외에 공유 &Pin 작동하지 않습니다. 참조)? 해결 방법이 Pin 에서 PinMut 되고 공유 사례에 대해 Pin 유형이 추가되었습니다. 이것은 이전 버전과 호환되지는 않았지만 브레이킹 체인지 ( Pin 에서 PinMut )가 이미 이루어졌고 이것이 이미 효과적으로 받아 들여 졌다고 확신합니다.

나는 그것이 거의 그것을 덮고 있다고 생각합니다. 모두 볼 수 있듯이 (원시 포인터와 deref 결정 외에, 후자는이 시점에서 대부분 해결 된 것으로 보입니다) 고정이 오늘 안정화 되었음에도 불구하고 이전 버전과 호환되는 경로가 있습니다. 더 중요한 것은 필드 프로젝션을 해결할 수 있다는 사실은 API에서 고정 된 유형을 사용하는 것이 나중에 후회하게 될 결정이 아니라는 것을 의미합니다.

위의 질문 외에도 훨씬 더 근본적인 방법으로 고정을 재고하려는 다른 제안이있었습니다. 내가 가장 잘 이해한다고 생각하는 두 가지는 !Unpin 유형 !DynSized 을 만들라는 @comex 제안과 steven099 (내부적으로 미안합니다. Github 이름을 모릅니다) 제안입니다. 내부를 움직일 수 없게 만드는 새로운 크기가 지정되지 않은 Pinned 래퍼 유형이 있습니다 (ZST 래퍼와 유사 함).

!DynSized 옵션은 불투명 한 유형을 처리하는 데 이미 필요할 수 있다는 이점이있는 상당히 보수적 인 기능입니다 (Rust가 이미 유사한 특성을 사용할 수 있다는 의미에서). 이러한 의미에서 Drop 대해 제안 된 변경 사항보다 덜 침습적 일 수 있습니다. !Unpin 유형이 !DynSized 이므로 !DynSized Drop 문제를 자동으로 해결하므로 이점에서 벗어날 수 없습니다. 이렇게하면 T 이 !DynSized 경우 &mut T 및 &T 자동으로 PinMut 및 Pin !DynSized 로 작동하므로 &mut T 에서 작동하는 고정 된 버전의 유형 및 메서드가 확산 될 필요가 없습니다 (필요하지 않은 경우 DynSized 바인딩을 요구하지 않도록 수정 된 경우). ).

?Trait 대한 일반적인 우려 사항 외에 주요 단점은 !Unpin 유형은 이동할 수 없다는 것입니다. 이는 현재 고정 된 유형의 상황과는 상당히 다릅니다. 이것은 참조를 사용하지 않고 두 개의 고정 된 유형을 작성하는 것이 실제로 가능하지 않다는 것을 의미하며 (어쨌든 내가 말할 수있는 한) 이에 대한 제안 된 해결책이 있는지 또는 방법이 확실하지 않습니다. IIRC 이것은 &move 제안과 함께 작동하도록 의도되었지만 그 의미가 무엇인지 잘 모르겠습니다. 나는 또한 불투명 한 유형에 의존하기 때문에 어떻게 안전한 필드 프로젝션을 가질 수 있는지 (제안에서) 이해하지 못합니다. 일반적으로 사용하려면 안전하지 않은 코드를 많이 사용해야하는 것 같습니다.

크기가 지정되지 않은 Pinned<T> 유형은 정신적으로 다소 유사하지만 ZST로 유형을 감쌀 수 있도록 허용하여 위의 문제를 해결하려고합니다 (효과적으로 크기가 지정되지 않은 상태로 작동). Rust는 현재 매우 비교할만한 것이 없습니다 : PhantomData 은 실제로 유형의 인스턴스를 포함하지 않으며 다른 동적 크기 유형은 뚱뚱한 포인터를 생성하고 여전히 이동을 허용합니다 ( size_of_val 에 의존하는 API 사용) ?DynSized 이 고치기위한 것이므로이 제안은 아마도 그 특성에 다시 피기 백 될 것입니다). 안전한 프로젝션을 허용하면이 제안이 실제로 Drop 문제를 해결하는 것 같지 않고 Deref 와도 호환되지 않는 것처럼 보이므로 Pin 보다 이점이 있습니다

이 보증을 유지하는 스택 고정 API가 비동기로 작동하도록 만들어 질 수 있다면 / 대부분의 이해 관계자가 이것을 기꺼이 받아들이기를 기다립니다 (IIRC 누군가 이미 생성기를 사용하여이 문제를 해결하려고 시도했지만 rustc ICE'd)

참고로, 이것은 아마도 중첩 된 생성기 기반 스택 고정 API에서 시도한 https://github.com/rust-lang/rust/issues/49537 을

아직 해결되지 않았습니다. 대부분 제안 된 스택 고정 API가 손상 될 수 있기 때문입니다. 이 보증을 유지하는 스택 고정 API가 비동기로 작동하도록 만들 수 있다면 / 대부분의 이해 관계자가 이것을 기꺼이 받아들이는 것처럼 보입니다 (IIRC 누군가 이미 생성기를 사용하여이 문제를 해결하려고 시도했지만 rustc ICE'd).

나는 이것에 대한 해결책으로 클로저 기반 스택 고정 API를보고있다. (한 번 &pin 은 (는 한 번 매크로 기반 솔루션 도 있습니다.

원시 포인터는 무조건 고정 해제해야합니까? [...] 이전 버전과 호환되지 않을 것입니다. 나는 주로 그 이유 때문에 이것을 논란의 여지로 표시하고 있습니다.

impl Unpin for Vec<T> 를 추가하는 것이 하위 호환성이 있지만 원시 포인터에 대해 동일한 작업을 수행하지 않는 이유는 무엇이라고 생각하십니까?

가장 큰 단점은 (? Trait에 대한 일반적인 우려를 제외하고)! Unpin 유형은 이동할 수 없다는 것입니다. 이는 현재 고정 유형의 상황과는 상당히 다릅니다. 이것은 참조를 사용하지 않고 두 개의 고정 된 유형을 작성하는 것이 실제로 가능하지 않다는 것을 의미하며 (어쨌든 내가 말할 수있는 한) 이에 대한 제안 된 해결책이 있는지 또는 방법이 확실하지 않습니다. 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 }
}

따라서 두 개의 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) }
    }
}

그러나 기존 디자인과 마찬가지로 매크로는 사용자가 Drop 대해 TwoGenerators Drop 를 구현하지 못하도록해야합니다. 반면에 이상적으로 컴파일러는 impl Drop for Pinned<TwoGenerators> 합니다. 현재 "Drop 구현은 전문화 할 수 없습니다"라는 오류와 함께이를 거부하지만 변경할 수 있습니다. 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 -ish 디자인을 사용하는 동기의 일부로 언급하고 있습니다. 나는 &'a Pinned<T> 가 포인터 유형의 조합 폭발을 피하기 때문에 이미 Pin<'a, T> 보다 낫다고 생각합니다. 그러나 동일한 문제 중 일부를 상속합니다.

1. 기본적으로 초기 이동 가능 상태가없는 유형을 지원하지 않습니다.
2. 시끄럽고 혼란스럽고 (동일한 유형에 대한 고정 된 참조와 고정되지 않은 참조의 차이점은 설명하기 어렵습니다), 고정 된 유형은 2 등급으로 느껴집니다. 나는 움직일 수없는 자기 참조 유형이 본질적으로 유용하고 자기 참조 값을 만드는 것이 쉽고 일반적인 다른 언어에서 온 사람들에게 Rust를 더 잘 보이게 만들기 때문에 최고 수준으로 느껴지기를 바랍니다.

미래에는 네이티브 고정 유형이 두 문제를 모두 해결할 것이며 대부분의 코드는 "핀"이라는 단어를 사용할 필요가 없습니다. ( Pinned 에는 여전히 일부 사용 사례가있을 수 있습니다. 복사 제거가 충분하지 않고 초기 이동 가능 상태가 실제로 필요한 경우) 이와 대조적으로 Pin 는 a "아직 고정되지 않은"상태를 사용하는 모든 특성의 디자인으로 분리합니다. 그리고 내장 된 &pin 는 그것을 언어로 구울 것입니다.

어쨌든, 위의 Pinned 디자인에 대한 플레이 그라운드 링크 가 있습니다.

[1] ... 정적으로 크기가 정해져 있지만 움직일 수도 있고 움직이지 않을 수도있는 유형에 대해 새로운 특성 ReallySized (덜 어리석은 이름)을 원할 수도 있습니다. 문제는 어쨌든 여기에서 약간의 변동이있을 것입니다. 크기가 지정되지 않은 rvalue에 대한 지원을 통해 현재 Sized 인수를받는 많은 함수가 크기가 조정되지 않았지만 이동 가능한 인수와 잘 작동 할 수 있기 때문입니다. 기존 함수의 경계와 향후 함수에 사용할 경계에 대한 권장 사항을 모두 변경할 예정입니다. 비록 이것이 몇 가지 단점이있을지라도, 향후 에디션에서 함수 제네릭에 대한 기본 (묵시적) 경계를 변경하는 것이 가치가 있다고 주장합니다.

[편집 : 고정 코드 예제]

뿡뿡

클로저 기반 스택 고정 API가 이에 대한 해결책으로, 더 인체 공학적이고 컴파일러에 의해 확인되는 미래의 길 (한 번 & pin은 언어 기본 요소)이 있습니다. @cramertj가 제안한 매크로 기반 솔루션도 있습니다.

클로저 기반은 async / await에서 제대로 작동하지 않습니다. 클로저 내에서 양보 할 수 없기 때문입니다. 하지만 매크로 기반은 흥미 롭습니다. 정말 안전하다면 꽤 독창적입니다. 범위가 떨어지는 동안 패닉이 다른 사람이 누출 될 수 있기 때문에 처음에는 작동하지 않을 것이라고 생각했지만 분명히 MIR로 해결 되었습니까?

또한 "메모리가 할당 해제되기 전에 실행되는 소멸자"보장과 고정 된 필드를 투영하는 기능 사이의 상호 작용에 대해서도 확신하지 못했습니다. 최상위 드롭이 당황하면 값에 고정 된 필드가 드롭되지 않을 것이라고 생각했습니다. 그러나 Rust 놀이터에서는 실제로 최상위 유형의 패닉 후에도 유형의 필드가 어쨌든 떨어지는 것처럼 보입니다. 그 보증은 실제로 어디에나 문서화되어 있습니까? 스택 고정이 핀 프로젝션과 함께 작동하는 경우 필요한 것 같습니다 (즉, PinDrop과 같은 더 무거운 무언가가 항상 패닉 상태에서 중단되므로 Drop과 PinDrop간에 기능 차이가 발생하므로 바람직하지 않은 것 같습니다).

Vec 용 impl Unpin을 추가하는 이유는이전 버전과 호환되지만 원시 포인터에 대해 동일한 작업을 수행하지 않습니까?

나는 당신의 요점을 봅니다 : 누군가가 소유 한 Vec<T> 필드에서 자동 !Unpin 구현에 의존하고 특정 !Unpin T 대해 고정이 전 이적이라고 가정 한 자체 접근자를 구현할 수 있습니다 PinMut<Vec<T>> 가 실제로 PinMut<T> 를 얻을 수있는 안전한 방법을 제공하지 않는 것은 사실이지만 안전하지 않은 코드는 여전히 PinMut::deref 를 이용하여 원시 포인터를 가져 와서 다음과 같은 가정을 할 수 있습니다. 포인터가 안정적입니다. 그래서 이것은 안전하지 않은 코드가 Vec (또는 무엇이든)을 통해 전이되는 !Unpin 에 의존하지 않는 경우에만 이전 버전과 호환되는 또 다른 상황이라고 생각합니다. 그러나 부정적인 추론에 대한 그런 종류의 의존은 어쨌든 나에게는 수상 쩍은 것처럼 보인다. !Unpin 이고 T 가 아닌지 확인하려면 항상 PhantomData<T> 추가 할 수 있습니다 (이 인수는 원시 포인터에도 적용됩니다). "표준 라이브러리의 유형이 유형 매개 변수에 관계없이 안전하지 않은 코드에서 고정 해제된다고 가정하는 것은 UB입니다. 유형이 명시 적으로 옵트 아웃하거나 해당 문서에서 이것이 신뢰할 수 있다고 선언하지 않는 한"이면 충분할 것입니다.

하지만 매크로 기반은 흥미 롭습니다. 정말 안전하다면 꽤 독창적입니다. 범위가 떨어지는 동안 패닉이 다른 사람이 누출 될 수 있기 때문에 처음에는 작동하지 않을 것이라고 생각했지만 분명히 MIR로 해결 되었습니까?

panic-during-drop으로 인해 나머지 지역 변수의 드롭을 건너 뛰는 것은 MIR의 버그입니다. 그것은 "보통 낙하"에서 "풀린 낙하"로 전환되어야합니다. 그러면 또 다른 패닉이 프로그램을 중단합니다.

뿡뿡

panic-during-drop으로 인해 나머지 지역 변수의 드롭을 건너 뛰는 것은 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 유형이 생성 될 때 TwoGenerators 자체의 Drop 대신 TwoGenerators Pinned 유형이 생성된다고 가정하더라도 (어떻게 작동할지 모르겠습니까?) Rust는 여전히 그렇지 않습니다. 프로젝션 된 모든 필드에 대해 생성자의 Pinned 버전을 호출하는 것을 알고 있어야합니다. 필드는 값으로 유지되기 때문입니다. 소멸자의 고정 된 버전이 존재하는 경우 항상 사용 되었다면 이것은 이상한 구문을 사용하는 PinDrop 와 실질적으로 동일하며 더 나은 방법을 알 수 없습니다.

그러나 값이 Pinned 에 뿌리를두고 있는지 재귀 적으로 분석하여 자신의 소멸자를 선택하는 것을 고려하고 싶은 유혹이 있습니다. 값별 특성 개체를 허용하려는 경우 컴파일 타임에 Pinned<T> 드롭 또는 T 드롭을 사용할지 여부를 결정할 수 있다는 점에 반드시 의존 할 수 없습니다. 그런 경우 Pinned 버전에 대해 별도의 vtable 항목이있을 수 있다고 생각하십니까? 이 아이디어는 나에게 일종의 흥미 롭다. 확실히 상당한 컴파일러 지원이 필요하지만 (제안 된 PinDrop 보다 훨씬 더), 어떤면에서는 전반적으로 더 좋을 수 있습니다.

그러나 스레드를 다시 읽으면 다른 문제가 있음을 기억합니다. 고정 된 유형에 대한 deref 구현은 Pinned<T> 실제로 제대로 작동하지 않습니다 ( deref 구현이 on PinMut 은 어떤면에서 논리적으로 잘못 되었기 때문에 계속 문제가 발생하지만 편리함을 감안할 때 손실을 정당화하는 것은 정말 어렵습니다. 한 무리의 유형을 무조건적으로 만들지 않는 한 Unpin 어쨌든). 특히, RefCell 예제가 Pinned::deref 존재하면 기존 유형으로 고정을 동적으로 적용 할 수 없음을 의미하므로 상당히 문제가됩니다. 전문화가 충분하다면). 이것은 더 우리가 유지하는 경우 제안 deref 구현을, 우리는 거의 많이와 API 표면을 복제 끝날해야합니다 Pinned 우리와 마찬가지로 Pin ; 보관하지 않으면 Pinned<T> 를 사용하기가 엄청나게 어려워집니다. 또한 아닌 것 같아 Box<Pinned<T>> 우리는 추가하지 않는 한 작동합니다 ?Move 별도로 ?DynSized (스레드에서 뾰족한 아웃 등).

이 모든 것이 좋은 생각 일 수 있지만 현재 Rust의 맥락에서 모든 것이 나에게 매력적이지 않은 것 같습니다. 특히 현재 Rust의 어떤 메소드도 기본적으로 ?Move 경계를 갖지 않는다고 생각할 때 (결핍을 의미합니다) deref 의 유형이 Unpin 이 아니면 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 사용하면 이동 불가능한 유형에 의해 impl'ed 될 것으로 예상되는 트레이 트의 메서드는 PinMut<Self> 를 가져야하고, 부동 유형을 참조하려는 일반 함수는 fn foo<T>(p: PinMut<T>) 와 같아야합니다. 반면에 Pinned 디자인은 Pinned<MyStruct> 대한 특성을 단순화 할 수 있기 때문에 대부분의 경우 새로운 특성이 필요하지 않습니다. 그러므로:

1. 움직일 수없는 유형은 메서드가 &self 또는 &mut self 사용하는 기존 트레이 트와 호환되지 않습니다. 예를 들어 생성기는 Iterator 단순화 할 수 없습니다. 따라서 기존 특성과 동일하지만 대신 PinMut<Self> 사용하는 새로운 특성이 필요합니다. 코스를 변경하고 PinMut<T> 를 &mut Pinned<T> PinMut<T> 의 별칭으로 만들면 돌아가서 모든 중복 특성을 폐기 할 수 있습니다.하지만 그것은 꽤 어리석은 일입니다. 처음에는 중복이 필요하지 않은 것이 좋습니다.

2. 반면에 새로 설계되거나 생성자 별 특성은 특성을 구현하고 싶지만 움직일 수없고 필요하지 않은 유형에 대해 노이즈를 추가하는 비용으로 PinMut<Self> 를 유일한 옵션으로 사용할 수 있습니다. 고정됩니다. (구체적으로 발신자는 &mut self 에서 PinMut<Self> PinMut::new 로 이동하려면 Self: Unpin 라고 가정합니다.) Pin<T> 가 &mut Pinned<T> 별칭을 사용하면 해당 소음을 제거 할 방법이 없습니다. 그리고 내가 구상하고있는 미래의 기본 고정형은 이동형 유형과 동일한 상황에있을 것이며, 항상 고정 된 것으로 간주 될 때 불필요하게 Pinned 로 래핑 될 필요가 있습니다.

나머지 게시물에 대해서는 두 번째 게시물에서 답변 해 드리겠습니다.

Drop

Drop 에 대해 말씀하신 내용에 약간 혼란 스럽지만 PinMut 와 하위 호환성을 만들려고하는 정도에 대해서는 생각하지 않겠습니다. 좋은 접근이라고 생각하지 않기 때문입니다.

가장 좋은 방법은 TwoGenerators 와 같은 구조체가있는 경우 두 가지 옵션이 있다는 것입니다.

1. TwoGenerators 또는 Pinned<TwoGenerators> 대한 수동 Drop impl 없음;
2. 당신은 IMPL Drop 에 대해 Pinned<TwoGenerators> ; 한편, 접근자를 제공하는 동일한 매크로는 TwoGenerators 자체에 대해 Drop impl을 생성하여 self를 &mut Pinned<TwoGenerators> 하고 삭제합니다. (이것은 안전합니다 : &mut T 를 &mut Pinned<T> 로 캐스트하는 데 필요한 불변성은 대여가 끝난 후 T 이동하지 않고 Drop , 해당 값에 대해 생성 될 마지막 차입금이 있습니다.)

두 가지 옵션이있는 유일한 이유는 이전에 언급했듯이 구조체가 Drop 을 (를) 단순화하지 않기를 원할 수 있다는 것입니다. impl을 구현하지 않는 구조체는 차용 검사기에 의해 더 느슨하게 처리되기 때문입니다.

고정 된 상태와 고정되지 않은 상태에 대해 실제 별도의 소멸자를 원하는 이유를 알 수 없으므로이를 구별하기 위해 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 는 대부분의 제안과 분리 될 수 있다고 생각합니다.

어쨌든 사용하기 어렵다면 Pin도 같은 문제가됩니다.

물론입니다. 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 , 거의 모든 라이브러리는 전혀 어떤 핀 관련 접근하지 않고 도망, 여전히 절반 괜찮은 지원 할 수 있습니다 !Unpin 유형.

반대로,? Sized 경계가있는 모든 것은 암시 적으로? Move입니다.

아 네, 좋은 지적입니다. 불행히도, Rust 코드 전체가 !Sized 바운드 유형에서는 작동하지 않습니다. 왜냐하면 기본값이 아니기 때문입니다. 그러나 적어도 일부 는 작동합니다. 크기가 지정되지 않은 값에 대해 수행 할 수있는 대부분의 작업은 & 또는 &mut 메서드 (예 : 슬라이스 또는 특성 개체)를 호출하는 것이기 때문에 그다지 이점이 없다고 생각합니다 & Pinned::deref 원하지 않기 때문에 귀하의 제안 ( Unpin 유형 제외)에 따라 수행 할 수 있습니다. #[derive] 구현으로 Pinned<T> 또는 그 밖의 다른 인스턴스를 생성하여 일반적인 경우를 처리 할 수 ​​있습니까?

Drop

개인적으로, 저는 Drop을 전문화하는 것이 정말 모호한 선례라고 생각하며 고정과 관련이없는 이유로 거의 확실히 바람직하지 않습니다. 따라서 이러한 본질적인 이점은 고려하지 않습니다. 어쨌든 저는 PinDrop이 나머지 제안과 대부분 분리 될 수 있다고 생각합니다.

나는 이것이 분리 가능하다는 데 동의하지만 그것이 모호하다고 생각하지 않습니다. 적어도… 당신이 옳다고 말한 것은 전문화의 한 형태입니다. 문자 그대로 Drop 의 일부 부모 블랭킷 impl을 전문화하지는 않지만 컴파일러에서 생성 한 드롭 글루는 구현 된 경우에만 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() }
}

따라서 현재 '특수화 된'Drop impls를 작성할 수없는 이유는 전문화 자체가 현재 불일치 한 이유와 동일한 이유라고 생각합니다. trans (수명 매개 변수를 지우는)와 typeck (그렇지 않은) 사이의 불일치입니다. 즉, impl Drop for Foo<'static> 라고 쓸 수 있다면 codegen은 두 유형이 동일하다고 가정하기 때문에 Foo<'static> 뿐만 아니라 모든 Foo<'a> 대해 실제로 호출됩니다.

좋은 소식은 아마 알다시피 특수한 impls를 제한하는 방법을 찾아서 그러한 유형의 일관성을 만들 수 없다는 것입니다. 그리고 전문화는 결국 그러한 제한과 함께 제공 될 것으로 예상됩니다. 그런 일이 발생하면 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> 를 사용하므로 이동식 유형에 대한 이러한 특성의 impl조차도 PinMut 를 받아야합니다. 함께 Pinned 내가 말했듯이, 특성이 걸릴 계속 &self 또는 &mut self , 당신은 그들을 IMPL 것 Pinned<MyStruct> . Vec<T> 대해 동일한 특성을 단순화하려면 Pinned 이 그림에 나올 필요가 없습니다.

그러나 잠재적 인 소스 중 하나는 필드 접근 자 매크로입니다. 당신이 가지고 있다면

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 ); 크기가 지정되지 않은 rvalue를 사용하면 ptr::read 및 mem::swap 및 mem::replace 대한 제한 ( Sized 에서 완화됨)이됩니다. 만약 우리가 &move 를받는다면 그것은 당신이 하나에서 벗어나게 할 수있는 한계가 될 것입니다. 보장 된 복사 제거에도 유사한 내용이 적용됩니다.

따라서 특성이있는 한 Pinned::deref (및 deref_mut )에 T: Move 바운드를 적용하지 않을 이유가 없습니다.

[편집 : pythonesque가 나에게 상기 시켰 듯이, 이것은 Unpin 와 다른 의미를 가지고 있으므로 신경 쓰지 마십시오.]

(그리고 Vec 및 Box 유형은 요소 유형이 Move 인지 여부에 관계없이 적용되도록 Move 수동으로 impl을 원할 것입니다.)

어 ... 좋아요, 제 진술을 수정하겠습니다. Pinned :: deref는 존재해야하지만 Unpin에 묶여 있어야합니다.하지만 Move라고 부르겠습니다.

좋아요, 잠시만 요. ?Move 또는 Move 입니까? 전자는 !Unpin 유형이 많은 경우에 생성 될 수도 없음을 의미합니다. 후자는 정확히 어떻게 우리가 Pinned<T> 와 같은 유형을 참조하는지 궁금하게 만듭니다 ( ?DynSized 가 실제로 올바른 경계가 아니기 때문에). 나는 그들이 하나이고 동일하지 않기를 바랍니다. 그렇지 않으면 Move 를 Unpin 하면 우리가 피하려는 정확한 일을 다시 한 번 수행하고 생성되는 순간 유형을 움직이지 않게 만듭니다.

단점은 & T를 취하는 특성이나 기능과 호환되지 않지만 별도로 Self : Sized bound; 그러나 그것들은 상대적으로 드물고 종종 의도하지 않습니다.

훨씬 더 실질적인 단점이 있습니다.이 특성이나 기능 중 일부가 실제로 & Pinned에서 작동한다는 것입니다.오늘. 그들은 그것과 함께 작동하도록 만들 수 있지만 엄청난 수의 추가 특성 구현과 (내가 말했듯이) 기존 #[derive] 구현의 상당한 개편이 필요할 것입니다. 이것은 또한 새로운 항목에 대해서도 지불해야하는 비용입니다. !Unpin 유형에서 작동하려면 &Pinned<Self> 대해 모든 것을 구현해야합니다. 이 걸릴 특성에 대한 (훨씬) 더 나은 상황 &mut self 보다 PinMut ,하지만 더 나쁜 &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을 사용합니다., 따라서 움직일 수있는 유형에 대한 이러한 특성의 impls조차도 PinMut을 받아야합니다.

확실한! Pinned 버전의 가장 큰 장점은 가변 고정 참조에 대해 고유 한 특성이 필요하지 않다는 것입니다. 그러나 거의 모든 다른 시나리오에서 deref 가있는 PinMut 보다 나쁘거나 중립적입니다.

고정 된 접근 자와 고정되지 않은 접근자를 모두 갖는 것은 타당하지 않을 수 있지만, 둘 다 괜찮습니다.

안전하지 않은 코드를 요구하는 수동 접근자는 나에게 나쁜 생각처럼 들립니다. 그러한 제안이 어떻게 접근 자 생성을 안전하게 할 수 있는지 모르겠습니다 (누군가가 고정 되지 않은 접근자를 제공 unsafe 를 작성하지 않고 제공 하지 못하도록 막는 방법은 무엇입니까?). 그러나 아시다시피 Move (실제로 Unpin 의미한다고 가정)하면 잘 작동합니다.

따라서 특성이있는 한 T : Move 바운드와 함께 Pinned :: deref (및 deref_mut)를 사용하지 않을 이유가 없습니다.

확실한. 여기서는 !Unpin 유형에 대해 구체적으로 이야기하고 있습니다. Unpin 유형은 PinMut 에도 구성 문제가 없으므로 내 관점에서 관련성이 없습니다. 그러나 제네릭에 대한 Unpin (또는 Move ) 경계는 유쾌하지 않으며 이상적으로는 가능한 한 피할 수 있어야합니다. 또, 같은 내가 말했듯이 : Unpin 에 의해 암시되고 어떤 !Sized 동일하지 않습니다 내가 당신 같은 존재로 취급 할 수 있다고 생각하지 않습니다.

…하지만 예, 고정 된 경우가 아니라 이동 특성이 필요합니다. 예를 들어, 새로운 버전의 size_of_val에 대한 경계의 일부가됩니다. 크기가 지정되지 않은 rvalue를 사용하면 ptr :: read 및 mem :: swap 및 mem :: replace에 대한 경계 (Sized에서 완화됨)가 될 것입니다. 우리가 & move를 얻는다면 그것은 당신이 한 곳에서 벗어나게 할 수있는 한계가 될 것입니다. 보장 된 복사 제거에도 유사한 내용이 적용됩니다.

나는 이것이 다시 한 번 !Unpin (유형이 기본이 아닌 고정 불변을 가질 수 있음을 의미 함)과 !DynSized -like !Move 합친 것이라고 생각합니다. 원치 않는 동결 동작을 일으키지 않고는 실제로 동일 할 수 없습니다.

죄송합니다. 당신 말이 맞습니다. Unpin 는 Move 와 같을 수 없습니다.

그래서 저는 다시 Unpin 믿고 있다고 생각합니다. 따라서 Pinned::deref 는 전혀 존재하지 않아야하며, 대신 접근 자 생성 매크로와 같은 상황을 피해야합니다. &Pinned<MovableType> 와 같은 유형을 가져옵니다. 하지만 별도의 특성으로 존재해야한다는 주장이있을 수 있습니다.

이번에는 Pinned 만으로 Vec 의 API 표면에있는 모든 특성을 다시 구현하는 것은 나에게 그다지 좋지 않은 것 같습니다 (특히 일부 특성이 작동하지 않기 때문에). 사례별로 Deref 를 선택적으로 구현하거나 (예 : &Pinned<Vec<T>> 를 &[Pinned<T>] 로 이동) Vec 전체를 그대로 두는 중 하나를 확신합니다 Unpin (핀 프로젝션을 허용하지 않음)이 훨씬 더 정상입니다.

예, 저는 Vec 의 전체 API 표면 또는 이와 유사한 것을 다시 구현할 것을 제안 할 의도가 없었습니다.

Vec 에서 "핀 프로젝션"을 허용하지 않는 것이 좋습니다. &Pinned<Vec<T>> 은 (는) 외부 불변 인 것처럼 보이므로 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 버전의 가장 큰 장점은 가변 고정 참조에 대해 고유 한 특성이 필요하지 않다는 것입니다. 그러나 거의 모든 다른 시나리오에서 deref 가있는 PinMut 보다 나쁘거나 중립적입니다.

또한 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의 일반 생태계에 옵트 인 할 수 없다는 것은 엄청나게 파괴적 일 것입니다 (사실, 내가 움직일 수없는 유형에 대한 거의 모든 사용 사례가 훨씬 더 어려워 질 것입니다).

나는 당신이 여기에서 의미하는 바를 완전히 이해하지 못하지만 그것은 당신이 내 실수에 대해 반응했기 때문일 수 있습니다 wrt Unpin 대 Move :)

이제 수정 되었으니 ... Unpin 이 있으면 Vec 가)이를 단순화해야합니다. 그러나 그것이 존재하지 않는다고 가정 할 때 당신이 언급하는 시나리오는 정확히 무엇입니까?

필드 중 하나가 Vec 구조체의 경우 필드에 대한 고정되지 않은 참조를 얻는 방법을 위에서 설명했습니다 (고정 된 참조를 얻을 수 없다는 대가로 괜찮습니다).

유형 매개 변수에 따라 Vec 포함 할 수있는 필드가있는 일반 구조체를 원하거나 유형 매개 변수에 따라 고정 유형을 포함 할 수있는 경우 이것이 문제가 될 것이라고 생각합니다. 그러나 구현 여부에 대해 모든 것이 생각해야하는 Unpin 특성없이이를 해결하는 다른 방법이있을 수 있습니다.

@comex

대안으로 Vec에서 변환을 허용하는 것은 어떻습니까?Vec에게>, 대부분의 Vec API가 있지만 재 할당을 유발할 수있는 메서드를 생략하는 것은 무엇입니까?

때문에...

즉, 현재 구조체 Vec에서 Vec의 정의를 변경합니다.Vec를 구성하려면, 좀 덜 어리석은 이름의 경우 기본적으로 Sized는 ActuallySized + Move의 별칭이됩니다. 그런 다음 재 할당을 유발할 수있는 메서드에 Sized 바운드를 추가하고 변환을 수행하는 메서드를 추가합니다.

... 정말, 정말 복잡하게 들리며 실제로 원하는 작업을 수행하지 않습니다 ( &mut Pinned<Vec<T>> 등에서 일반 Vec<T> 얻음). 사실 이후에 벡터를 고정 할 수 있다는 것은 일종의 멋진 일입니다. 따라서 Box<Pinned<T>> 와 좋은 유사점을 얻을 수 있습니다.하지만 이는 직교 문제입니다. 고정이 소유 된 유형의 속성이 될 수 있다는 사실을 보여주는 또 다른 예일뿐입니다. Unpin 에 대한 모든 것은 참조 유형이 어떻게 구성되는지에 대한 질문과 거의 전혀 관련이 없다고 생각합니다.

이제 수정 되었으니 ... Unpin이 존재한다면 Vec은 그것을 단순화해야합니다. 그러나 그것이 존재하지 않는다고 가정 할 때 당신이 언급하는 시나리오는 정확히 무엇입니까?

나는 이것이 내 요점을 설명 할 것이라고 생각하기 때문에 이에 응답 할 것이다. PinMut 없이는 Unpin PinMut 를 통해 i32 필드를 변경할 수도 없다. 어떤 시점에서 당신은 당신이 자주 (완전히 변하지 않는 한) 그 안에 뭔가를 이동해야 당신의 구조 아무것도 할하려는 경우. Pinned<MyType> 에서 필드 접근자를 명시 적으로 구현해야하는 사람들이 필요한 것은 특히 문제의 필드가 항상 이동하기에 안전하다면 정말 성가신 것 같습니다. 이 접근법은 또한 빌트인 Pinned 유형과 함께 사용하는 것이 정말 혼란스러워 보입니다. 왜냐하면 합법적 인 프로젝션은 필드 유형에 의존하지 않는 방식으로 필드에 따라 다르기 때문입니다. Rust에서 이미 거부 된 것입니다. mut 필드가 제거되었을 때 (그리고 IMO, 그러한 주석을 추가하려는 경우 unsafe 가 더 나은 선택입니다. 안전하지 않은 필드는 실제로 큰 발판이기 때문입니다). 내장 고정 유형은 고정 된 열거 형을 사용하기 좋게 만드는 유일한 방법이므로 나머지 언어와 어느 정도 일관성을 유지할 수 있는지에 대해 신경을 씁니다.

하지만 더 중요한 것은 ...

유형 매개 변수에 따라 Vec를 포함하거나 이동할 수없는 유형을 포함 할 수있는 필드가있는 일반 구조체를 원하는 경우 이것이 문제가 될 것이라고 생각합니다.

그것은 Unpin 의 킬러 사용 사례이며 (저에게) 실제로 작동하는 것처럼 보인다는 사실은 꽤 환상적이며 전체 고정 모델을 검증합니다. Rust 1.0 이전에는 Unpin 를 그대로 유지하고 싶을 것입니다.) 구조에서 인라인에있는 일반 매개 변수도 현재 계획이 Unpin 로 바인딩해야하는 유일한 시간입니다 (거의 모든 안전한 참조 유사 유형이 무조건 Unpin 구현하도록 함). 통과.

그러나 내가 정말로 얻지 못하는 것은 : 왜 Unpin 를 제거하고 싶습니까? 그것을 제거하면 본질적으로 아무것도 사지 않습니다. Pinned 에서 PinMut (또는 그 반대)를 통해 얻을 수있는 모든 멋진 것들은 그 존재와 거의 관련이 없습니다. 추가하면 나머지 Rust 생태계와 쉽게 호환됩니다. FWIW, Unpin 및 Pin 에 대한 deref 의 무조건 구현은 Unpin 없이는 모든 유형이 동일하게 느껴진다는 점을 제외하면 서로 거의 관련이 없습니다. !Unpin 유형이 수행하는 고통 (무조건적인 deref 구현을 더 유용하게 만들 수 있음을 의미 함). 나는 도울 수 없지만 내가 뭔가를 놓치고 있다고 느낀다.

드롭되는 구조의 다른 필드가이 컨텍스트에서 지역 변수로 간주됩니까? 사용자가 직면 한 문서에서 나에게 명확하지 않습니다.

충분히 공평하게, 나는 이것을 추적하기 위해 https://github.com/rust-lang/rust/issues/50765 를 열었습니다.

안녕하세요.

특히 Pinned :: deref가 있으면 기존 유형으로 고정을 동적으로 적용 할 수 없다는 의미이기 때문에 RefCell 예제가 상당히 문제가됩니다 (전문화가 충분한 지 모르겠습니다). 이것은 우리가 deref 구현을 유지한다면 우리가 Pin에서하는 것처럼 Pinned로 API 표면을 거의 복제해야한다는 것을 의미합니다. 보관하지 않으면 고정됨사용하기가 놀라 울 정도로 어려워집니다.

용 용액 RefCell 별도의 방법 제공하는 것이다 borrow_pin 및 borrow_pin_mut (복용 Pin<RefCell<T>> ) 및 내부의 고정 된 상태를 추적 RefCell 런타임에 PinMut 및 Pinned 모두에서 작동합니다. 그렇다면 Pinned 가 도움이되지 않는다는 당신의 주장이 있습니까? RefCell 도 상황을 더 악화시키지 않아야합니다.

하지만 당신은

차이점은 우리는 Pinned와 함께 작동하지 않는 것처럼 보이는 deref를 지원하면서 PinMut과 함께 솔루션을 함께 사용할 수 있다는 것입니다.

그리고 나는 당신이 무엇을 언급하고 있는지 모르겠습니다. 왜 이것이 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 - 당신이 얻을 수있는 &mut 이전에 무언가에 PinMut . 그리고 Drop 는 안전합니다. 즉, Unpin 는 안전해야합니다 (이는 mem::forget 이고 다시 한 번 누수 발생).
2. 생성기를 고정 해제하지 않는 현재 선물 기반 API와 같은 것들이 self: PinMut<Self> ( unsafe impl Unpin 아님)을 사용하더라도 100 % 안전하게 구현할 수 있다는 의미이기 때문입니다.
3. Unpin 가 안전한 경우 API가 소리가 나나요? 대답은 예입니다. 생성기가 Unpin 구현하지 않고 프로젝트를 !Unpin 유형에 고정하는 것이 안전하지 않은 한 모든 것이 안전합니다.
4. 그러나 이것은 핀 돌출부가 안전하지 않다는 것을 의미합니다! 이상적이지 않습니다.
5. Self가 Unpin 또는 Drop [edit : true or false?]를 구현하지 않는 경우 고정 프로젝션은 안전

이 라이브러리 API에 대한 더 많은 언어 지원 대안에 대한 아이디어가 있습니다. 여기에는 Unpin 완전히 삭제하고 대신 극성을 뒤집는 것이 포함됩니다. 대신 이러한 보증 을 받기 Pin 특성입니다. 옵트 아웃 . 그러나 이것은 상당한 언어 지원이 필요하지만 현재 구현은 전적으로 라이브러리 기반입니다. 좀 더 깊이 생각한 후에 다른 글을 올릴 게요.

내가 계속 잊어 버리기 때문에 또 다른 메모 :

핀 프로젝션 안전성은 필드 유형이 아닌 자체 유형 에만 의존합니다. 필드 유형은 무조건적인 공개 API의 안전성을 보장해야하기 때문입니다. 따라서 재귀 검사가 아닙니다. Self 이 Pin 에서 아무것도 이동하지 않으면 모든 유형의 필드에 핀 투영이 안전합니다.

@withoutboats FWIW 이것은 @cramertj 와 제가 이전 토론에서 도달 한 결론과 정확히 일치합니다. 그리고 저는 처음에는 파생물에서 내 보낸 일부 특수 목적 속성을 통해 상호 배제 검사를 자동화 할 수 있다고 믿습니다.

안녕하세요.

기본적으로 Drop은 고정 해제와 동일한 권한을 제공합니다. 이전에 PinMut에 있던 항목에 대해 & mut을 얻을 수 있습니다. Drop은 안전합니다. 즉, Unpin이 안전해야합니다 (이는 mem :: forget 및 leakpocalypse입니다).

나는 leakpocalypse와의 연결을 보지 못하지만 그렇지 않으면 동의합니다. 내가 조금 주저하는 유일한 이유는 Drop 이면 많은 사람들이 신경 쓸 필요가없는 코너 케이스처럼 느껴졌 기 때문입니다. 그것이 장점인지 아닌지 확실하지 않습니다. 어쨌든 안전한 Unpin 는 여기에서 일관성을 높이고 Drop 문제를 더 이상 특별한 경우로 만들지 않음으로써 문제를 "해결"할뿐만 아니라 모든 impl Drop 과 같이 생각할 수 있습니다. 암시 적 impl Unpin 와 함께 제공됨); 당신이 말하는 것에서 그것은 또한 사물의 Future 쪽에서 사용하기가 더 쉽습니다. 그래서 전체적인 승리 인 것 같습니다.

@pythonesque 내가 뭔가를 Unpin 는 침입 컬렉션에 대한 새로운 문제를 일으키지 않습니다. 안전한 Drop 에도 불구하고 일했다면 여전히 일해야합니다.

안녕하세요.

Self가 Unpin 또는 Drop을 구현하지 않는 경우 Pin 투영은 안전합니다. [edit : true 또는 false?] 검사를 자동화 할 수 있습니까?

처음에 여기에서 필드 유형을 언급했으며 왜 이것이 관련이 있다고 생각하는지 물어 보려고했습니다. 이제 게시물을 편집하는 것을 봅니다. :) 이것은 Self 유형에 대해서만 동의합니다. 다음에서 나는 내 관점에서 당신의 주장을 거의 반복한다.

본질적으로 질문은 Self 가 고정 불변을 어떻게 선택합니까? 기본적으로 우리는 (안전하지 않은 코드가 있더라도!) 고정 불변이 소유 된 불변과 정확히 동일하다고 가정합니다. 즉, 고정은 위치와 독립적이며이 유형은 고정을 수행하지 않습니다. PinMut<T> 로 &mut T 로 바꾸는 것 외에는 아무것도 할 수없는 한, 그것은 안전한 가정입니다.

필드 프로젝션을 사용하려면 고정 불변이 대신 "모든 필드가 해당 유형의 불변에 고정됨"이어야합니다. 이 불변은 필드 유형에 관계없이 고정 투영을 쉽게 정당화합니다 (즉, 원하는 고정 고정 불변을 선택할 수 있음). 물론이 불변성은 PinMut<T> 를 &mut T 로 바꾸는 것과 호환되지 않으므로 이러한 유형이 Drop 또는 Unpin 가 아닌지 확인하는 것이 좋습니다.

나는 leakpocalypse와의 연결을 보지 못하지만 그렇지 않으면 동의합니다.

단지 비유-Unpin은 mem :: forget이 Rc 사이클에 대한 것처럼 Drop하는 것입니다. mem :: forget은 원래 안전하지 않은 것으로 표시되었지만 이에 대한 정당성은 없었습니다. (그리고 Rc 사이클이 엣지 케이스라는 동일한 주장이 mem :: forget safe 표시에 대해 만들어졌습니다.)

Discord에서 (영적으로) 복사-붙여 넣기, 저는 우리가 문제를 뒤집지 않았다는 증거를보고 싶습니다 : Unpin을 안전하게 구현하고, 구조적 핀 접근자를 구현하기에 안전하지 않게 만들어 (이것은 또한 어떤 도입 된 안전하지 않은 특성, 맞습니까? 여전히 안전하지 않은 코드를 작성해야합니다). 이것은 대부분의 시간이 완전히 안전하기 때문에 나를 괴롭 힙니다. 기본적으로 유형에 대한 명시적인 Unpin impl이없는 한 유형에 대한 Drop impl이없는 경우 항상 안전합니다. 현재 계획에서 우리는 훨씬 더 강력한 것을 요구하고 있습니다. 타입에 대한 명시적인! Unpin impl이 있어야 합니다. 이것은 훨씬 적은 타입에 대해 사실 일 것입니다 (즉, 라이브러리에서 할 수있는 모든 것입니다).

불행히도 저는 컴파일러가 특정 유형에 대한 수동 Unpin impl이 있는지 여부를 확인할 수 있는지 여부를 알지 못합니다. "has any impl"과는 대조적으로 특수화와의 상호 작용이 좋지 않은지 확실하지 않습니다. 유형의 작성자가 구조적 고정을 얻기 위해 안전하지 않은 코드를 작성할 필요가 없도록 해당 검사를 수행하는 확실한 방법이 있다면 impl Unpin 가 안전하다는 것이 훨씬 더 행복 할 것입니다. ... 그게 실현 가능한 것 같습니까?

나는 지금 이해하려고하는 간단한 질문이 있습니다. 제네릭에서 모든 제네릭 매개 변수에 대한 API가 아닌 경우 고정 해제는 크기가 지정된 암시 적 바운드입니까?

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 Arc 밖으로 이동할 수 있습니다. 이를 제거하거나 T: Unpin 경계를 도입하는 것은 이전 버전과 호환되지 않는 변경입니다.

안녕하세요!
핀 접근자가 안전하게 작동하도록하는 방법에 대해 약간 생각하고 있습니다. 내가 아는 한, 핀 접근 자 문제는 T: !Unpin + Drop 조합이있을 때 _only_ 발생합니다. 이를 위해 T 유형의 존재 가능성을 방지하려는 논의를 보았습니다. 예를 들어 !Unpin 및 Drop 을 다양한 방식으로 상호 배타적으로 만들었지 만 이전 버전과의 호환성을 깨지 않고이를 수행하는 명확한 방법이 아닙니다. 이 문제를 더 자세히 살펴보면 유형이 !Unpin 및 Drop 인 것을 방지하지 않고 안전한 Pin 접근자를 얻을 수 있습니다. 단지 그러한 유형을 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 내부에 배치 할 수 있음) 유형이 모두 필요한 가능성이없는 * 경우에 Drop 를 수행 할 수 있습니다 unsafe impl Pinnable 유형에 따라

* 저는 Pin 대한 경험이 없지만 !Unpin 유형에 대해 impl Drop 가 필요한 대부분의 경우가 원인이 아니기를 바랍니다. 삭제해야하는 것은 본질적으로 !Unpin 이지만 Drop 필드와 !Unpin 필드가있는 구조체로 인해 발생합니다. 이 경우 Drop 필드는 !Unpin 필드를 포함하지 않는 자체 구조체로 분리 될 수 있습니다. 필요한 경우 더 자세히 설명 할 수 있습니다. 그 설명이 어리석은 것 같기 때문입니다. 그러나 이것은 주석의 본문이 아니므로 지금은 짧게 남겨 두겠습니다.

내가 아는 한, 핀 접근 자 문제는 T :! Unpin + Drop 조합이있을 때만 발생합니다.

"and"보다 "or"에 가깝습니다.

핀 접근자는 고정에 대한 "구조적"해석을 의미합니다. T 가 고정되면 모든 필드도 고정됩니다. 반면에 impl Unpin 및 Drop 는 유형이 고정에 전혀 관심이 없다고 가정하기 때문에 안전합니다. T 고정되거나 차이가 없습니다. 특히 T 의 필드는 두 경우 모두 고정되지 않습니다.

그러나 나중에 !Unpin + !Drop 유형이 접근자가 안전하게 추가 할 수있는 유형이라고 말했을 때 바로이 결과를 얻었습니다. (유형은 여전히 안전하지 않은 코드에서 잘못된 작업을 수행하지 않도록주의해야하지만 Unpin ad Drop 는 고정 접근자를 차단하는 두 가지 안전한 방법입니다.)

이 문제를 좀 더 자세히 살펴보면 타입이되는 것을 막지 않고 안전한 Pin 접근자를 얻을 수 있습니다! Unpin and Drop, 단지 그러한 타입은 Pin에 넣을 수 없다는 것입니다..

나는 따르지 않는다. 그게 왜 충분하다고 생각하세요? 그렇다면 유형을 고정 할 수없는 경우 고정 된 접근 자에 관심이있는 이유는 무엇입니까?

"and"보다 "or"에 가깝습니다.

지금은 이것에 대해 이야기 해 봅시다. 제 전체 아이디어가 이것의 반대에 기반을두고 있었기 때문에 제가 이것을 오해했다면 나머지 아이디어는 도움이되지 않습니다.

이해 내 (현재)로, 인 유형 핀 접근 Unpin 관계로, 낙하, 완전히 건전한 Pin<T> 효율적입니다 &mut T 어쨌든. 또한 !Drop 유형의 핀 접근자는 !Unpin 유형의 경우에도 완전히 건전합니다. drop 는 &mut self 얻을 수있는 유일한 함수이기 때문입니다. !Unpin 유형에서 Pin 를 입력하면 아무것도 이동할 수 없습니다.

내가 잘못한 경우 알려주세요. 그러나 그렇지 않은 경우 Unpin + Drop 유형 또는 !Unpin + !Drop 유형은 핀 접근 자에서 완전히 문제가 없으며 유일한 문제 유형은 !Unpin + Drop 입니다.

헉헉

또한,! Drop 유형의 핀 접근자는! Unpin 유형의 경우에도 완전히 소리가납니다. drop은 핀에 들어가면! Unpin 유형에서 & mut self를 얻을 수있는 유일한 기능이므로 아무것도 할 수 없습니다. 물건을 밖으로 옮기십시오.

struct Foo(InnerNotUnpin); impl Unpin for Foo {} 를 쓰면 PinMut<Foo> 에서 PinMut<InnerNotUnpin> 로 이동하는 것은 불건전합니다. 프로젝션이 소리가 나도록하려면 (a) drop impls를 금지하고 (b) 필드가 Unpin 경우에만 구조가 Unpin 인지 확인해야합니다.

(a) !Unpin 것에 드롭 임플란트를 금지해야합니까?
(b) Unpin 구현이 안전하지 않다는 사실에 의해 처리되어야합니다. 유형이 실제로 고정 해제 될 수 없을 때 고정 해제 될 수 있다고 안전하지 않게 주장하여 자신을 쏠 수 있다는 사실을 확인해야합니다. Sync 일이 있어서는 안되며 그런 식으로 불건전 한 행동으로 끝납니다.

(a) 그냥 물건에 드롭 임플란트를 금지해야합니다!

예,하지만 이전 버전과의 호환성 때문에 불가능합니다.

그리고 그것은 내 요점에 도달합니다. 그러나 우리는! Unpin이 발생하는 것을 막을 필요가 없습니다. 유형의! Unpin 마커는 의미가 없으며 해당 유형이 Pin 안에있을 때까지 약속을하지 않습니다. 따라서! Unpin 유형의 drop impl은 해당 유형이 Pin_ 안에 있지 않는 한 완전히 소리가납니다. 제가 제안하는 것은 Pin을 Pin<T> 에서 Pin<T: Pinnable> 로 변경하는 것입니다. Pinnable 트레이 트는 Drop + !Unpin (또는 그 이상 일반적으로 핀 접근자가 문제가되는 유형)은 Pin 안에 넣습니다.

그 시점에서 당신은 Unpin 특성을 완전히 쓸모 없게 만들고 있지 않습니까? 또한 현재 Rust로는 필요한 경계를 표현할 수 없습니다. " Unpin 와 Drop 가 호환되지 않습니다"라고 말할 수 있다면 문제가되지 않습니다. Pinnable 와 비슷한 것이 필요한 것 같습니다. 이것이 어떻게 도움이되는지 모르겠습니다.

Unpin 특성은 자체적으로 이미 "쓸모없는"특성입니다. _only_ 특성은 유형이 고정되면 유형이 Pin으로 이동하기 전에 이동할 수 있다는 것을 의미합니다.

@RalfJung 과 저는 방금 이러한 API에 대해 이야기하기 위해 회의를 가졌으며 주요 API 변경없이 API 를 안정화 할 준비가되어 있다는 데 동의했습니다.

미해결 질문에 대한 해결

핀 API에 대한 나의 믿음은 다음과 같습니다.

1. PinMut 및 Unpin 의 핵심 API 개념은 기본 제공 언어 지원을 포함하지 않는 최상의 솔루션을 구성합니다.
2. 이러한 API는 필요하다고 판단되는 경우 향후 기본 제공 언어 지원을 배제하지 않습니다.

그러나 우리의 결정을 기록하고 싶은 한계와 절충점에 대한 몇 가지 뛰어난 질문이 있습니다.

Drop 의 문제

RFC를 병합 할 때까지 발견하지 못한 한 가지 문제는 Drop 특성의 문제였습니다. Drop::drop 메서드에는 자체 &mut self 를 취하는 API가 있습니다. 이것은 본질적으로 Self "고정 해제"이며 고정 된 유형이 제공해야하는 보장을 위반합니다.

다행히도 이것은 우리가 핀으로 투사하려는 핵심 "이동식 생성기"유형의 건전성에 영향을 미치지 않습니다. 이들은 소멸자를 구현하지 않으므로 !Unpin 구현은 실제로이를 의미합니다 .

그러나 이것이 의미하는 바는 직접 정의한 유형의 경우 반드시 "고정 해제"하는 것이 안전하며 Drop 구현하기 만하면됩니다. 이것이 의미하는 바는 Unpin 가 unsafe trait 라는 것은 우리에게 추가적인 안전을 제공하지 않는다는 것입니다. Drop 를 구현하는 것은 건전성에 관한 한 Unpin 를 구현하는 것만 큼 좋습니다. 걱정.

이러한 이유로 우리는 Unpin 트레이 트를 구현하기에 안전한 트레이 트로 만들었습니다.

핀 투영

현재 API의 주요 제한 사항은 필드가 Unpin 구현하지 않을 때 핀 프로젝션을 수행하는 것이 안전하다는 것을 자동으로 결정할 수 없다는 것입니다. 핀 투영은 다음과 같습니다.

U 유형의 a 필드가있는 T 유형이 주어지면 다음 액세스를 통해 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 구현 하지 않는 한 rustc가 이것이 안전하다는 것을 _prove_ 할 필요가 없습니다. 즉, 이러한 종류의 프로젝션 방법을 구현하려면 현재 안전하지 않은 코드가 필요합니다. 다행히도 안전하다는 것을 증명할 수 있습니다. 필드 유형이 Unpin 구현하지 않는 경우 다음 항목이 모두 유지되는 경우에만 안전합니다.

1. Self 유형은 Unpin 구현하지 않거나 필드 유형이 수행 할 때 조건부로 Unpin 만 구현합니다.
2. Self 유형은 Drop 구현하지 않거나 Self 유형의 소멸자는 해당 필드에서 아무것도 이동하지 않습니다.

언어 확장을 사용하면 컴파일러가 이러한 조건 중 일부가 유지되는지 확인할 수 있습니다 (예 : Self 는 Drop 구현하지 않고 조건부로 Unpin 만 구현 함).

안정된 특성 인 Drop 문제로 인해이 문제는이 문제에 대해 우리가 내릴 수있는 모든 결정이 이미 존재했으며, 언어 변경 없이는 핀 투영을 자동으로 안전하게 만들 방법이 없습니다. 언젠가는 이러한 변경을 할 수 있지만 이에 대한 이러한 API의 안정화를 차단하지는 않을 것입니다.

"핀"보증 지정

RFC 프로세스 후반에 @cramertj 는 고정 된 생성기에 필요한 것 이상으로 약간 확장하면 고정을 사용하여 침입 목록의 보장을 안전하게 캡슐화 할 수 있음을 깨달았습니다. Ralf는 여기 에이 확장에 대한 설명을 썼습니다.

기본적으로 고정 보장은 다음과 같습니다.

PinMut<T> 가 있고 T 이 Unpin 구현하지 않는 경우 T 는 이동되지 않고 T 의 메모리 백업은 이동되지 않습니다. 소멸자가 T 대해 실행될 때까지 무효화 됩니다.

이것은 "누수 자유"와 정확히 같지 않습니다. T 는 예를 들어 Rc주기 뒤에 갇혀서 여전히 누수 될 수 있지만 누수 되더라도 메모리가 무효화되지 않음을 의미합니다 (프로그램이 실행될 때까지 종료), 소멸자가 실행되지 않기 때문입니다.

이 보장은 스택 고정을위한 특정 API를 배제하므로 처음에는이를 포함하도록 고정을 확장하는 것에 대해 확신 할 수 없었습니다. 그러나 궁극적으로 다음과 같은 몇 가지 이유로이 보증을 사용해야합니다.

1. 이 매크로 와 같이 훨씬 더 인체 공학적인 스택 고정 API가 발견되어 단점을 제거했습니다.
2. 상승은 꽤 큽니다! 이러한 종류의 침입 목록은 Rust를 가비지 수집 언어와 통합하는 josephine 과 같은 라이브러리에 매우 영향을 미칠 수 있습니다.
3. Ralf는 이러한 API 중 일부가 처음부터 제대로 작동하는지 확신하지 못했습니다 (특히 "영구 차용"에 기반한 API).

API 재구성

그러나 API에 대한 마지막 제안 변경 사항을 만들고 싶습니다. 존재하는 API를 검토 한 Ralf & I는 Drop 등과 관련된 높은 수준의 보증 및 불변성을 설명 할 좋은 장소가 없다는 것을 깨달았습니다. 따라서 나는 제안한다

1. 새로운 std::pin 모듈을 만듭니다. 모듈 문서는 고정에 대한 높은 수준의 개요, 제공하는 보증 및 안전하지 않은 부분의 고정 사용자가 유지할 것으로 예상되는 높은 수준의 개요를 제공합니다.
2. PinMut 및 PinBox 를 std::mem 및 std::boxed 에서 pin 모듈로 이동합니다. std::marker 모듈에는 다른 마커 특성과 함께 Unpin 를 남겨 둡니다.

또한 이러한 유형의 안정화를 완료하기 전에 더 광범위한 문서를 실제로 작성해야합니다.

Unpin 구현 추가

Ralf와 나는 또한 표준 라이브러리에 Unpin 의 더 많은 구현을 추가하는 것에 대해서도 논의했습니다. Unpin 구현할 때 항상 절충안이 있습니다. Unpin 가 필드 유형과 관련하여 무조건 구현되면 해당 필드에 프로젝트를 고정 할 수 없습니다. 따라서 지금까지 Unpin 구현에 대해 그다지 공격적이지 않았습니다.

그러나 우리는 원칙적으로 다음과 같이 믿습니다.

1. 포인터를 통한 핀 투영은 절대 안전한 것으로 취급해서는 안됩니다 (아래의 메모 상자 참조).
2. 내부 가변성을 통한 핀 투영은 절대로 안전한 것으로 취급해서는 안됩니다.

일반적으로 이러한 작업 중 하나를 수행하는 유형은 핀 프로젝션을 사용할 수 없게 만드는 작업 (예 : Vec 에서 백업 저장소 재 할당)을 수행합니다. 따라서 포인터 뒤 또는 UnsafeCell 내에서 일반 매개 변수를 보유하는 std의 모든 유형에 Unpin 의 무조건 구현을 추가하는 것이 적절하다고 생각합니다. 예를 들어 여기에는 std::collections 모두 포함됩니다.

나는 너무 면밀히 조사하지 않았지만 이러한 impls를 추가하면 대부분의 유형에 충분할 것이라고 생각합니다.

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

하지만 한 가지 잔소리가 있습니다. 기술적으로는 Box 통해 투영되는 핀이 기술적으로 안전 할 수 있다고 믿습니다. 즉, PinMut<Box<T>> 에서 PinMut<T> 것이 안전하게 수행 될 수 있습니다. 이것은 Box 가 절대 자신을 재할 당하지 않는 완전 소유 포인터이기 때문입니다.

T: Unpin 때 Box<T> 대해서만 Unpin 가 조건부로 구현되도록 구멍을 제공 할 수 있습니다. 그러나 내 개인적인 의견은 고정이 제자리에 고정 된 메모리 블록에 관한 것이라고 생각할 수 있어야하므로 포인터 간접을 통한 모든 투영은 안전하지 않아야한다는 것입니다.

안정화를 차단하지 않고이 결정을 지연하고 시간이 지남에 따라 이러한 impls를 추가 할 수 있습니다.

결론

지금까지 핀 API에 많은 투자를해온 다른 사람들의 생각과이 안정화 계획이 합리적으로 들리는 지 여부를 듣고 싶습니다. 나머지 언어 팀을 위해 후속 게시물에서 fcp 제안으로 더 짧은 요약을 만들 것입니다.

@rfcbot fcp 병합

저는 약간의 재구성 후에 기존 핀 API를 안정화 할 것을 제안합니다. 내 이전 게시물 에서 더 긴 요약을 읽을 수 있습니다. 내 의견의 TL; DR은 현재 API가 다음과 같다는 것입니다.

• 소리
• 언어 변경없이 얻는만큼 좋은
• 더 나은 언어 변경과 호환 가능

우리는 지난 몇 달 동안 정확한 보장 및 고정 고정에 관한 모든 주요 질문을 해결했으며, 현재 우리가하고있는 결정 (안정되어야 할 결정)은 더 긴 게시물에 문서화되어 있습니다.

실제로 상황을 안정화하기 전에 몇 가지 변경 사항을 제안합니다.

1. PinMut 및 PinBox 를 새로운 std::pin 모듈 아래에서 재구성합니다. 여기에는 일반적으로 고정 및 고정 보장에 대한 높은 수준의 문서가 포함됩니다.
2. 포인터 간접 뒤 또는 UnsafeCell 내부에 일반 매개 변수를 포함하는 std의 유형에 대해 Unpin 의 무조건 구현을 추가하십시오. 이러한 구현이 적절한 이유는 더 긴 요약에 나와 있습니다.

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

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

현재 나열된 문제가 없습니다.

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

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

@rfcbot fcp 취소

나는 또한 우리가 내려야하는 핵심적인 결정으로 인해 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 분에 boats [email protected]이 다음과 같이 썼습니다.

@bstrie 문서화 전에 FCP를 제안하는 것이 우리의 표준 절차입니다. 나는 추적 문제를 따르지 않은 모든 사람들에게 충분한 정보를 제공해야하는 플레이 상태에 대한 매우 광범위한 요약 주석을 작성했습니다.

—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하십시오.

안녕하세요.

포인터를 통한 핀 투영은 절대 안전한 것으로 취급해서는 안됩니다 (아래의 메모 상자 참조).
내부 가변성을 통한 핀 투영은 절대로 안전한 것으로 취급해서는 안됩니다.

이 점을 조금 명확히 할 수 있습니까? 특별히 표준 라이브러리의 유형 Box 와 유사하게 Mutex 와 같은 유형은 콘텐츠를 고유하게 소유하기 때문에 고정을 계획 할 수 있습니다 (대역 외). 적어도 표준 라이브러리 외부에서는 PinMut<T> 에 대한 호출에서 .lock() PinRef<InPlaceMux<T>> 에서 PinMut<T> 프로젝트하는 동시성 프리미티브를 가질 수있는 기능을 원한다고 가정합니다. "내부 가변성을 통한 투영"의 경우처럼.

@cramertj Mutex 투사하는 것은 위험 해 보입니다. &Mutex 안전하게 변환 한 다음 Mutex::lock 를 사용하여 &mut 를 얻은 다음 물건을 옮길 수 있습니다.

편집 : 오, 당신은 항상 고정 된 Mutex 합니다. PinMutex 처럼. 예, 작동합니다. &mut 를 절대로주지 않으면 내부 변경은 괜찮습니다. 그러나 현재 libstd에 그러한 데이터 구조가있을 것 같지는 않습니다.

그러나 예, 완전한 정밀도를 위해 @withoutboats '문을 수정하여 "내부 가변성을 통한 핀 투영은 유형이 항상 고정되는 경우에만 안전합니다. 즉, 절대 &mut 하지 않습니다."

@RalfJung 정확히 맞습니다.

그러나 현재 libstd에 그러한 데이터 구조가있을 것 같지는 않습니다.

맞습니다. 포인터 나 내부 변경 가능성을 통해 투영하지 않는 것에 대한 명시된 요구 사항이 일반적인 규칙이 아닌 libstd에 관한 것임을 확인하고 싶었습니다.

@cramertj 확실히 어렵고 빠른 규칙은 아니지만 (예를 들어 위반하는 UB가 아닙니다) 불확실한 사람들에게 좋은 지침이라고 말하고 싶습니다

이것을 안정화하기로 한 결정에 실망합니다. 컴파일러 지원이 없으면 잠재적 인 디자인이 약간 엉망인 것처럼 보일 것이기 때문에 단기적으로 일어나는 일에 대해 지나치게 걱정하지 않습니다. 그러나 장기적으로 Rust가 네이티브 고정 유형을 얻는다면 &self 및 &mut self 허용하는 트레이 트 메서드와 함께 사용할 수없는 한 진정한 일류라고 느껴지지 않을 것입니다. 결과적으로 고정 성은 참조 유형이 아니라 참조 유형의 속성이어야합니다. 물론 이는 네이티브 고정 유형에 대한 향후 디자인에서 여전히 발생할 수 있습니다. 그러나 이는 Pin<T> 중복되는 결과를 초래할 것입니다. 예를 들어 일부 기본 &pin T 대해 더 이상 사용되지 않는 별칭 일뿐만 아니라 모두 불필요합니다. 차례로, Pin<Self> 를 허용하는 Future (및 잠재적으로 다른 많은 것)과 같은 특성을 수정하거나 더 이상 사용하지 않아야하므로 복잡한 전환 기간이 필요합니다.

불가능하지 않은 지저분한. 그러나 지나치게 비관적 일 수 있다는 위험을 감수하면서 그러한 전환을 피하려는 욕구가 향후 결정을 기본 고정 유형의 기초로 대신 &pin 를 채택하는쪽으로 편향 될 것이라고 걱정합니다. 영구적으로 이등입니다. 그리고 저는 여전히 단기적인 디자인 중에서 &Pinned<T> 접근 방식이 실현 가능했을 것이라고 생각합니다. 이러한 포워드 호환성 문제를 피하고 다른 이점도 제공합니다 (예 : 내부 가변성 문제를 완전히 회피).

오 잘. 그대로, 나는 여전히 Pin 를 사용하기를 고대하고 있지만 표준 라이브러리에 들어가는 것보다 crates.io에 머물렀다면 더 선호했을 것입니다.

나는 이것을 안정 시키기에는 너무 이르다는 데 동의합니다. 의 필드에 액세스 할 때 현재는 예를 들어, 어떤 상황에서 다소 어색 !Unpin 호출 방법 내부 유형을 PinMut<Self> . @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 futures-rs에는 PinMut 안에 유형이 있지만 해당 필드 중 하나가 고정 된 것으로 간주되지 않는 상황이 있습니다.

@withoutboats 의 매크로의 단점은 self 대한 가변 참조를 보유하고 있기 때문에 한 번에 하나의 필드에만 액세스 권한을 부여 할 수 있다는 것입니다. 구조체 필드 액세스에는이 제한이 없습니다.

고정 API를 안정화하기로 결정하는 것이 올바른 결정이라고 생각합니다. 그러나 제안 된 core::pin 모듈을 먼저 구현하는 것이 좋습니다.

Drop 특성에 여전히 문제가 있지만 유형의 필드에 액세스하는 것보다 더 큽니다.

아니에요. Drop 은 필드 매핑을하지 않는 한 실제로 괜찮습니다. 이것이 필드 매핑이 안전하지 않은 이유입니다.

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에 대한 가변 참조를 보유하고 있기 때문에 한 번에 하나의 필드에만 액세스 할 수 있다는 것입니다. 구조체 필드 액세스에는이 제한이 없습니다.

여러 필드에 대한 액세스 권한을 부여하는 메소드를 작성할 수 있지만 관심있는 각 조합에 대해 작성해야합니다.

호기심으로 인해 미래 외에 다른 구체적인 사용 사례가 있습니까, 아니면 적어도 지금 (나중에 더 많은 경험을 가진 것과는 반대로) 안정화하려는 욕구를 자극하는 다른 무언가가 있습니까?

@comex가 제기 한 요점에 대해서는 여기에서 더 이상의 논의가없는 것 같습니다. 참조 대신에 pin 유형의 속성으로 만드는 아이디어가 기억 나지 않기 때문에 그들은 저를 꽤 궁금하게 만들었습니다. 이것은 이미 다른 곳에서 논의 되었습니까? "외부"에서 모든 것을 따르는 것은 쉽지 않습니다. 최선을 다합니다 ;-)

차례로 Pin을 허용하는 Future (및 잠재적으로 다른 많은)와 같은 특성변경되거나 사용되지 않을 필요가 있으며 복잡한 전환 기간이 필요합니다.

흠. 일부 에디션 관련 마법을 사용하면이 Pin 를 자동으로 래핑 및 래핑 해제하고 변경 사항을 완전히 이전 버전과 호환되도록 만들 수 있습니까? 다소 총체적이지만 과도하지는 않으며 이러한 전환 중에 언어와 API를 깨끗하게 유지합니다.

이 질문에 답하기 위해 아이디어를 더 구체화해야 할 수도 있습니다 (이전에 스레드에서 제기 된 것을 기억하지만 어디 있는지 추적하지 못했습니다).

@yasammez 저는 여기 에서 가치 지향적 고정에 대한 논의를 선택할 수있었습니다.

확인하기 위해 안정화 경로에 안전한 현장 투영 계획이 포함되어 있지 않습니까? 이것은 모든 미래 라이브러리에 안전하지 않은 코드를 많이 도입 할 것 같습니다. 내 경험상 수동 Future impls는 드문 일이 아니며 내 모든 것이 필드 폴링이 필요하다는 것을 알고 있습니다.

이 안전하지 않은 코드의 대부분이 사소하게 안전하다는 것이 입증되는 것은 중요하지 않다고 생각합니다. 안전하지 않은 코드의 존재만으로도 실제 안전하지 않은 코드를 감사 할 수있는 능력이 희석됩니다.

가까운 시일 내에

1. Futures 라이브러리가 개발 한 unsafe_pinned 매크로와 같은 매크로를 사용하여 모든 내부 폴에 대해 하나의 안전하지 않은 것으로 제한합니다.이 매크로는 내 긴 요약에 설명 된 제약 조건에 대해 확인해야합니다 (매크로 및 매크로를 사용할 수도 없습니다. 접근자를 손으로 작성하십시오. 단 하나의 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 를 수동으로 구현하지 않고 대신 auto trait impl에 의존합니다.
2. 사용자 지정 소멸자가 없기 때문에 미래를 위해 Drop 를 수동으로 구현하지 않았습니다.
3. 투사하려는 필드는 비공개입니다.

이 경우 : 당신은 좋습니다! unsafe_pinned는 사용하기에 안전합니다.

수동으로 구현 않은 경우 Unpin 또는 Drop , 당신이 실제로 그것에 대해 생각해야하지만, 심지어 그 경우는 반드시 이러한 어려운 문제 :

1. Unpin 구현했다면 Unpin 추상화하는 미래에 제약을받습니다.
2. Drop 구현했다면 소멸자 동안 퓨처 필드를 이동하지 않습니다.

참조를 위해 @tikue , 속성 기반 솔루션에 대한 기본 제안 의

적절한 &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 에는 확실히 안전하다고 생각합니다. 소멸자를 "in place"라고 부르고 메모리를 재사용하기 때문입니다. 그러나 나는 가치가 조기에, 즉 수명이 끝나기 전에 하락하는 것에 대해 PinMut 에 대해 약간 걱정됩니다. 이것이 항상 괜찮을 것이라는 것이 분명하지 않은 것 같지만 반례를 제시 할 수도 없습니다. 트윗 담아 가기 @cramertj @withoutboats 어떤 생각?

(할 수 있다면 @rfcbot에 추가하겠습니다 ...)

@rfcbot 우려 교체

@RalfJung 나는 여기에서 틀릴 수 있지만 T 패닉이 발생하면 코드가 두 번 떨어질 수 없습니까?

@RalfJung 이미 PinMut::set 있습니다.

@cramertj 도우. 그래 그래 내가 좀 더 철저히 확인했을 수 있었어.

소음에 대해 죄송합니다. 우려 사항이 해결되었습니다.

@rfcbot 해결 교체

이것은 선물 0.1 => 0.3 tokio_timer::Deadline 와의 호환성을 위해 지금 작성중인 실제 코드입니다. 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)
        };

안전하지 않은 사소한 사용 외에도 컴파일 된 버전을 찾기 위해이 코드를 약 5 번 반복했습니다. 여기서 무슨 일이 일어나고 있는지에 대해 글을 쓰고 생각하는 것은 인체 공학적이지 않습니다.

안전하지 않은 것에 대한 전면적 인 금지와이 코드 사이에는 많은 여지가 있다고 생각합니다. 예를 들어 map_unchecked 는 참조를 반환해야하기 때문에이 코드를 지원하기에는 너무 제한적이지만이 코드에서는 Future01CompatExt<&mut Delay> 반환해야합니다.

편집 : Unergonomy의 또 다른 소스는 매치 가드에서 가변적으로 빌릴 수 없기 때문에 PinMut다음과 같은 코드로 작업 할 수 없습니다.

```녹
self.poll_listener (cx)와 일치합니까? {
// self.open_connections> 0 인 경우
Poll :: Ready (None) if self.open_connections ()> 0 => {
^^^^ 패턴 가드에서 가변적으로 빌려
return Poll :: Pending;
}
설문 조사 :: 준비 (없음) => {
return Poll :: Ready (None);
}
}
````

map_unchecked에 대한 귀하의 의견은 정점에 있으며 포인터 주위에 임시 반환을 허용 할 수있는보다 일반적인 서명이있을 수 있습니다.

PinMut<Type> 의 필드에서 &mut 참조를 얻는 것이 안전한시기에 대한 지침이 있습니까? Type 필드가 고정되었다고 가정하지 않는 한 괜찮습니까? 비공개 여야합니까?

예, 필드가 Unpin 구현하거나 필드의 PinMut 를 구성하지 않습니다.

@rfcbot 분산

나는 상당한 양의 PinMut 기반 코드를 작성하고 있는데 한 가지 많이 발생하는 것은 고정에 의존하지 않는 작업을하고 있지만 PInMut 의해 스스로 걸립니다. &mut 보다는 "나는이 기억에서 벗어나지 않겠다고 약속한다." 그러나 이렇게하면 모든 사용자가 고정 된 값을 갖게되므로 불필요합니다. 나는 그것을 생각하고 있고 그것에 대한 좋은 API를 찾을 수 없었지만, "고정 될 나의 주장이 필요하다"와 "고정 된 것으로 작업 할 수있다"를 분리하는 방법이 있다면 멋질 것입니다. 논의".

저는 "변이"가 잘못된 용어라고 생각합니다. 원하는 것은 다른 참조 유형에 대해 추상화하는 연관된 유형 생성자입니다.

@RalfJung 네, 맞습니다. 그러나 나는 PinMut 또는 & mut에서 올 수있는 것과 같은 유형에 만족하지만 PinMut처럼 만 사용할 수 있습니다. 따라서 이것이 특히 잘 확장되지 않는다는 것을 알고 있습니다. 나는 그것이 일반적인 임의의 _self_types보다 더 성취 할 수 있다고 생각합니다. : smile : 아마도 "우리는 다음과 같은 기능을하는 서명을 미래에 대비할 수 있다고 상당히 확신합니다"로 마무리하는 것이 가장 좋습니다.

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

@rfcbot 우려 API 리팩터링

약간의 영감을받은 구조체와 어젯밤에 저는이 API를 리팩토링하여 모든 단일 포인터의 고정 된 버전을 만들지 않고 포인터를 래핑하는 Pin 유형이 하나만 있도록하는 방법을 알아 냈습니다. 이것은 어떤 식 으로든 API의 근본적인 재구성은 아니지만 "메모리 고정"구성 요소를 구성 가능한 조각으로 끌어내는 것이 더 좋습니다.

• 다음은 새로운 API를 설명하는 블로그 게시물입니다.
• 코드를 보여주는 요점은 다음과 같습니다.

nt-rs 의 네트워크 스택에서 작업 할 때 고정 된 참조가 여기 에서 볼 수있는 fold 로 현재 해결중인 "소유권 댄스"에 도움이된다고 들었 습니다 (tx.send가 tx를 Send<<type of tx>> 미래, 패킷을 보내기 위해 들어오는 데이터를 반복하기 어렵게 만듭니다.). 고정이 그런 일에 어떤 도움이 될까요?

@Redrield send() 는 선물에서 &mut 본인을 받습니다 .0.3 .

@withoutboats 저는 futures-rs에서이 새로운 API를 사용해보고 싶습니다!

새 API는 다른 식별자를 사용하기 때문에 두 API를 동시에 사용할 수 있어야한다고 생각합니다. 두 API를 모두 사용할 수있는 짧은 전환 기간을 갖는 것이 가장 좋을 것 같습니다.이를 통해 실험하고 PR을 준비하고 libcore의 futures API를 새로운 스타일로 이식 할 수 있습니다.

@MajorBreakfast 잠재적으로 type PinMut<T> = Pin<&mut T>; 별칭을 지정하고 동일한 방법을 여러 개 제공 할 수있는 것 같습니다. 이렇게하면 파손의 규모와 즉각적인 문제를 줄일 수 있습니다.

안녕하세요.

따라서 새로운 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> ( &self.inner 가 안전한 &Smaht<T> 필요는 없음).
2. Smaht<T>: DerefMut 이면 DerefMut::deref_mut(&mut self.inner) 호출하면 유효한 Pin<&mut T::Target> ( &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 (myself)는 Own 특성에서 own 메서드의 목적이 무엇인지 묻습니다. 왜 옵트 인하려는 유형이 pinned 를 구현하도록 남겨 둘 수 없습니까? 이렇게하면 특성이 안전하고 Own 보다 덜 어색하게 느껴지는 Pinned 이름을 지정할 수 있습니다. 자신의 방법에 대한 이유는 충분하지 않은 것 같습니다.

다른 질문을 추가하겠습니다.

왜도 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 만 사용할 수 없습니까?

이 두 impls는 작성 방법 외에는 전혀 차이가 없습니다.

핀이없는 이유

자체도 핀

:: new_unchecked P로 제한됨 : Deref?

나는 의견이 없습니다. 역사적으로 std 라이브러리는 구조체에 묶여 있지 않았지만 그 정책이 동기가 좋은 것인지 아니면 역사적인 사고인지 확실하지 않습니다.

# 53227이 착륙 한 후이를 구현할 계획이지만 논란이 많기 때문에 Own 특성을 구현하지 않을 것입니다. 지금은 Box , Rc 및 Arc 의 pinned 고유 생성자 Arc 있습니다.

@ arielb1이 작성한 내용에 따라, 저는 여기서 Pin 을 실제로 "포인터 유형 생성자"에 대해 작동하는 것으로 봅니다. Box 또는 &'a mut 와 같은 "종류" * -> * 물론, 우리는 실제로 그것에 대한 구문을 가지고 있지 않지만 그것은 불변성 측면에서 이것을 이해할 수있는 방법입니다. 우리는 여전히 4 개 (안전성 ( 내 블로그 게시물에서와 같이 유형별 불변 : 소유, 공유, 고정 소유, 고정 공유.

Pin<Ptr><T> 는 T 의 불변을 가져 와서 변형 (모든 곳에서 고정 된 불변 사용) 한 다음 Ptr 을 적용하기 때문에 적절한 형식화에는이 뷰가 필요하다고 생각합니다 Ptr 생성자를 해당 결과 유형에 추가합니다. (이것은 우리가 Owned 정의하는 방식을 변경해야하지만 어쨌든 장기적으로 계획 한 것입니다.) 형식주의 측면에서는 Ptr<Pin<T>> 를 작성하는 것을 선호하지만 시도해 보았습니다. 그것은 Rust와 잘 작동하지 않습니다.

그러면 포인터 유형 생성자가 Pin "옵트 인"할 때 만드는 약속은 Deref / DerefMut 를 적용하는 것이 안전하다는 것입니다. 입력이 실제로 Ptr 유형의 고정 소유 / 공유 변형에 적용되면 출력은 해당 유형의 고정 소유 / 공유 변형을 충족합니다.

이것들은 실제로 여기에서 유일한 두 가지 "안전하지 않은 방법"입니다 (불변성에 대해주의해야한다는 의미에서) :

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))
    }
}

이 두 사람 은 새로운 작업을 수행하지 않는다는 점을 가정하고 as_ref / as_mut 를 Pin<&[mut] T> 에서 &[mut] T 로 안전하게 변환합니다. - 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가 물건을 복사하는 한 가지 상황을 잊었다는 것을 깨달았습니다.하지만 지금은 큰 문제가 아닐 것입니다. 나는 패킹 된 구조체에 대해 이야기하고 있습니다. 패킹 된 구조체에 삭제가 필요한 필드가있는 경우 rustc는 해당 필드의 데이터를 정렬 된 어딘가에 복사하는 코드를 내 보낸 다음 drop 를 호출합니다. 이는 &mut 전달 된 drop 가 실제로 정렬되었는지 확인하는 것입니다.

우리에게 이것은 repr(packed) 구조체가 "구조적"또는 "재귀 적"wrt가 아니어야 함을 의미합니다. 고정-구조체 자체가 고정 된 경우에도 필드가 고정 된 것으로 간주 할 수 없습니다. 특히, 그러한 구조체에서 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 구현하기 때문입니다).

종합 하면 완전히 안전한 코드로 고정 된 값을 이동할 수 있습니다 .

이것은 의도 된 것입니까? 이것이 안전한 이유에 대한 근거는 무엇입니까?

Pin<&mut Box<...>> 이있는 것 같습니다. Box 은 (는) Box 내부 항목이 아니라 Box 는 스택에 해당 위치에 대한 참조를 저장하지 않기 때문에 항상 Box 를 이동하는 것이 안전합니다.

원하는 것은 Pin<Box<...>> 입니다. 놀이터 링크 .

편집 : 더 이상 정확하지 않음

@Pauan Box 가 고정되어 있다고해서 _inside_가 고정 된 것은 아닙니다. 이것에 의존하는 모든 코드는 올바르지 않습니다.

당신이 찾고있는 것은 아마도 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 용입니다). 다음 은 올바른 Nightly 링크입니다.

아, 마지막으로 사용한 이후로 규칙이 바뀌었나 봐요. 혼란을 드려 죄송합니다.

@tmandry 예, 변경 사항은 매우 최근입니다. 상황이 여전히 유동적이기 때문에 모든 변화를 따라 가기가 어렵습니다.

@tikue 의 의견이 정확합니다. 핀은 한 수준의 간접 방향 만 고정한다는 것을 기억해야합니다.

@tikue @tmandry @withoutboats 답변 주셔서 감사합니다! 매우 도움이되었습니다.

그렇다면 현재 두 가지 우려의 상태는 무엇입니까? ( 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 의 기본 impl을 파생 할 수 있습니다 (이후 Pin<&mut T> : DerefMut<Target = T> ) 및하기 PinDrop 자동적으로 사용되는 특성 수 rustc 에 (감사 Pin::new_unchecked(&mut self) 드롭 우리가 그것에 대해 생각할 때) 고정 스택의 경우에만이기 때문에.

다음은 아이디어의 대략적인 PoC입니다. https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=9aae40afe732babeafef9dab3d7525a8

어쨌든, imho 이것은 beta 남아 있어야하며 예외 일지라도 아직 안정되지 않아야합니다. Drop 동작이 compat을 깨지 않고 Unpin 에 의존 할 수있는 시간이 있다면 그 시간은 지금입니다.

@danielhenrymantilla impl<T> Drop for Vec<T> 와 같은 기존 일반 드롭 impls와의 호환성 문제를 어떻게 해결하는지 모르겠습니다.

다른 것이 필요합니다.
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>) 의 작은 안전 이득보다 더 큰 비중을 차지한다고 생각합니다

주소에서 Pin 유형 해싱에 대한 Hash 구현에 대한 논의가 있었습니까?

Pin 에는 포함 된 포인터에 단순히 위임하는 Hash 구현이있을 수 있습니다. 해시됩니다).