Rust에서 커스텀 스마트 포인터를 진짜 ‘일급’으로 만들기 위해, place 기반 설계와 투영(projection), 자동 참조, 재대여, 이동, 패턴 매칭, 인덱싱, 메타데이터 처리까지 아우르는 제안과 그 파급효과를 탐구합니다.
이 글은 Field Projections 프로젝트 목표에 대한 논의의 일부로 제안합니다. 매우 생산적인 논의를 이끌어 주신 Benno Lossin과 모든 분들께 감사드립니다!
Rust에서 커스텀 스마트 포인터를 가능한 한 일급(first-class)으로 만들려면 무엇이 필요할까요? 이 글에서는 별칭(aliasing)을 진지하게 다루었을 때의 결과를 탐구합니다.
이 생각들은 Zulip에서 시작되어 몇 차례의 반복을 거쳤습니다. 이 글은 그 제안의 스냅샷이며, 앞으로도 HackMD 문서에서 계속 발전할 수 있습니다.
이 섹션에서는 어떤 코드가 허용되어야 한다고 생각하는지, 그리고 그것이 기능 설계를 어떻게 이끄는지를 살펴봅니다.
Deref만으로는 불충분Deref와 DerefMut를 구현한 스마트 포인터 MyPtr이 있다고 가정합시다. 다음 코드는 borrowck 오류를 일으킵니다:
let mut x: MyPtr<Foo> = MyPtr::new(..);
let a = &mut x.a;
let b = &mut x.b;
*a = 0;
*b = 0;
이 코드는 MyPtr<Foo> 대신 &mut Foo나 Box<Foo>를 사용하면 허용됩니다. 이들은 대여 검사기(borrow-checker)에게 특별한 취급을 받기 때문입니다. 따라서 커스텀 스마트 포인터에서도 같은 수준을 원합니다.
디슈거링을 보면 오류의 이유가 드러납니다. 두 번째 deref_mut 호출이 a를 무효화합니다.
// 디슈거 결과:
let mut x: MyPtr<Foo> = MyPtr::new(..);
let deref_x: &mut Foo = (&mut x).deref_mut();
let a = &mut (*deref_x).a;
let deref_x: &mut Foo = (&mut x).deref_mut();
let b = &mut (*deref_x).b;
*a = 0;
*b = 0;
제가 내리는 결론: &mut x.a의 의미가 바뀌거나 확장되어야 합니다.
주: 처음에는 별칭 문제를 우려해 다중 필드 투영을 상상했습니다. 논의 이후로는, 스마트 포인터에
&mut/&참조가 들어 있다면 필드 단위 대여가 작동할 수 없다는 점이 분명해졌습니다. 다만 중간 투영에 원시 포인터(raw pointer)를 사용한다면 가능할 수도 있어서, 아직 결론 난 것은 아닙니다.
이 섹션의 이전 제목은 “한 번에 하나의 필드를 투영할 수 없다”였지만, 이제는 그렇게 생각하지 않습니다. 대신 다음과 같이 제안으로 받아들여 주십시오: 당장은 필드 단위가 아니라 한 번에 모두 투영하자는 것입니다.
Field Projections 이니셔티브의 기본적인 바람은 MyPtr<Foo>에서 원래 Foo의 특정 필드를 가리키는 MyPtr<Field>로 가는 방법을 제공하는 것입니다.
중요한 질문이 있습니다. 한 번에 하나의 필드를 투영할 수 있을까요? 즉, project!(x, field.a)를 project!(project!(x, field), a)로 구현할 수 있을까요?
가능하지만 주의가 필요합니다. 예를 들어 struct MyMutPtr<'a, T>(&'a mut T) 같은 타입에서는 필드 단위로 자유롭게 투영하고 서로 분리된 대여를 얻을 수 없습니다. 그런 행위가 UB를 만들 수 있기 때문입니다. 다만 중간 단계에서 *mut 포인터를 사용할 수는 있습니다.
그동안의 가설은 이렇습니다. 투영은 한 번에 모두 작동해야 하며, 중첩 투영을 수행할 때 중간 포인터 값을 만들지 말자는 것입니다. 필드 단위 케이스에 대한 논의는 여기에서 다룹니다.
진정한 일급을 위해서는 autoref가 “그냥” 작동해야 합니다:
impl Bar {
fn takes_shared(&self) { ... }
fn takes_mut(&mut self) { ... }
fn takes_my_mut(self: MyMut<Self>) { ... }
}
let x: MyMut<'_, Foo> = ...;
x.bar.takes_shared();
x.bar.takes_mut();
x.bar.takes_my_mut();
앞선 섹션에서 본 바와 같이, x.bar를 가리키는 MyMut를 만든 뒤 &Bar로 강제 변환하고 싶지는 않습니다. 한 번에 이뤄져야 합니다.
제가 내리는 결론: 스마트 포인터는 다양한 다른 포인터로 투영될 수 있도록 옵트인할 수 있어야 합니다. 대략 다음과 같이요:
trait Project<P: Projection, Target>
where
Self: PointsTo<P::Source>,
Target: PointsTo<P::Target>,
{
fn project(*const self, p: P) -> Target;
}
// 예: 대략 이런 식으로
impl<T, U, P: Projection> Project<P, &U> for MyRefMut<'_, T> {...}
impl<T, U, P: Projection> Project<P, &mut U> for MyRefMut<'_, T> {...}
impl<T, U, P: Projection> Project<P, MyRefMut<'_, U>> for MyRefMut<'_, T> {...}
위에서 중간 포인터 값을 만들고 싶지 않다고 했지만, 문법은 합성 가능해야 합니다. x.a.b는 (x.a).b와 같아야 하며, 각각의 구성요소가 의미를 가져야 합니다.
이미 Rust에는 이에 대한 해법이 있습니다. 바로 place 표현식입니다. x, *x, x.a, x.a.b는 모두 place를 나타내는 표현식입니다.
여러 요소가 관여합니다. 만약 x: &mut T이고 foo가 &self를 받는다면, x.a.foo()는 실제로 Foo::foo(&(*x).a)를 의미합니다. 여기서 *x는 타입 T의 place 표현식이며, (*x).a는 타입 Foo의 place 표현식입니다. 그런 다음 그 place를 &<place>로 빌려서 새로운 포인터를 만듭니다.
place는 또한 대여 검사기의 기반입니다. 별칭 등을 추론할 때 이미 우리가 다루고 싶은 바로 그 개념입니다.
제가 내리는 결론: place는 강력하며 사용자에게도 친숙한 개념이므로, 이를 적극 활용해야 합니다.
커스텀 스마트 포인터도 place를 통해 작동하도록 제안합니다. 즉, x: MyPtr<T>라면 *x는 타입 T의 place 표현식이 되고, “그 포인터로서 빌리기” 문법(바이크셰드 예정)으로 @MyPtr x.a.b 같은 것을 둘 수 있게 합니다. x.a.b.foo()의 전체 디슈거를 예로 들면 다음과 같습니다:
Foo::foo(@MyPtr (*x).a.b)
// 이 표현은 대여 검사를 거친 다음 대략 다음과 같은 메서드 호출로 컴파일됩니다:
Foo::foo(<MyPtr as Project>::project(&raw const x, projection_type!(T, a.b)))
저는 HasPlace 트레이트를 상상합니다. 만약 x: X이고 X: HasPlace이면, *x는 허용되고 타입이 X::Target인 place 표현식이 됩니다.
trait HasPlace {
type Target: ?Sized;
}
오늘날의 Rust에서 place에 대해 할 수 있는 일은 몇 가지가 있습니다.
let x = <place>;<place> = something();&<place>, &mut, &raw const, &raw mutmatch <place> { Some(_) => ..., None => ..., }저는 이러한 각 연산이 서로 다른 트레이트에 의해 관장되어야 한다고 제안합니다. 각 연산은 옵트인이므로, 예컨대 SoA(struct-of-arrays) 표현(글 마지막에 예시 있음)과 같은, 실제 메모리 영역과 1:1로 대응하지 않는 가상 place도 허용할 수 있습니다.
또한 각 스마트 포인터는 자체적인 대여 종류가 됩니다. 예컨대 x: Rc<T>라면 @RcRef (*x).a.b와 같이 쓸 수 있습니다(rcref 크레이트 사용). 이것이 바로 Field Projection 이니셔티브에서 논의되던 “포인터 투영(pointer projection)” 기능을 구현하는 방식입니다.
/// 어떤 타입이 다른 타입을 “담고(contain)” 있음을 나타냅니다. 스마트 포인터뿐만
/// 아니라, 감싼 타입을 “담거나 수정”하는 컨테이너/래퍼에도 사용됩니다.
///
/// `X: HasPlace`이고 `x: X`라면, 표현식 `*x`는 place 표현식이며 타입은
/// `X::Target`입니다. 이 place에서 가능한 동작은 아래의 다른 `Place*` 트레이트에
/// 의해 결정됩니다.
trait HasPlace {
/// 담긴 값의 타입.
type Target: ?Sized;
/// 담긴 값의 메타데이터를 가져옵니다. “메타데이터 처리” 섹션 참고.
unsafe fn metadata(*const self) -> <Self::Target as Pointee>::Metadata;
/// 대여 검사기에게, 동시에 혹은 이후에 어떤 다른 대여가 허용되는지 알려줍니다.
const BORROW_KIND: BorrowKind;
}
/// 같은 place에 대해, 동시에 혹은 이후에 어떤 다른 대여가 허용되는지를
/// 대여 검사기에게 알려줍니다. 예: `let y = @MyMutPtr x.a;`가 있고 `x.a`에
/// 또 다른 대여가 발생하면, `y`는 더 이상 사용할 수 없고 드롭되어야 합니다.
///
/// “이 place 안에서 어떤 대여를 유도할 수 있는가”는 `PlaceBorrow`가 관장합니다.
/// 예컨대 `Shared` place에서 `Unique` 대여를 유도할 수 없다는 식의 대여 검사기
/// 강제는 없습니다.
// TODO: 수명 매개변수 없이 이게 다 말이 되는가?
// TODO: 부모/자식 place에 대한 대여는 어떠한가? `&x.a.b`와 `&x.a`는 공존할 수
// 있지만 `&x.a.b`와 `&mut x.a`는 그렇지 않다.
// TODO: 다른 place 동작(읽기, 쓰기)과의 상호작용은? 더 많은 작업 필요.
#[non_exhaustive]
enum BorrowKind {
/// 다른 대여가 허용됩니다(`*mut T`, `RcRef<T>` 등과 유사).
Untracked,
/// 다른 `Shared` 동시 대여가 허용됩니다(`&T`와 유사).
Shared,
/// 다른 동시 추적 대여가 허용되지 않습니다(`&mut T`와 유사).
Unique,
/// 다른 동시 또는 이후의 대여가 허용되지 않습니다(`&own T`와 유사).
Owning,
/// 다른 동시 추적 대여가 허용되지 않으며, 기본 메모리를 회수하기 전에 반드시
/// `drop`이 호출되어야 합니다(`&pin mut T`와 유사).
UniquePinning,
// 아마 다른 것들도?
}
/// 타입 `Source`의 값 안에 있는 타입 `Target` 서브값의 위치를 설명합니다.
trait Projection: Copy {
type Source: ?Sized;
type Target: ?Sized;
// 이건 상수가 아닙니다. 왜 그런지는 “인덱싱 투영” 섹션 참고.
fn offset(self) -> usize;
// 타겟이 unsized일 때 필요합니다. “메타데이터 처리” 섹션 참고.
fn metadata(self) -> <Self::Target as Pointee>::Metadata;
}
/// 투영 타입의 명명. 모든 투영(구조체 필드, 유니언 필드, 열거자(variant) 필드,
/// 인덱싱)을 지원합니다.
/// 예: `projection_type((MyStruct.field[_].other_field as Some).0): Projection`
macro projection_type! { ... }
/// 필드를 허용하지 않는 `projection_type`의 별칭. 타입을 자기 자신으로 매핑하는
/// no-op 투영을 나타냅니다.
macro empty_projection! { ... }
/// 서브 place를 선택한 place 컨테이너 `X`로 “빌립니다(borrow)”.
///
/// 문법은 `@SmartPtr <place_expr>`입니다(내장 포인터의 경우 `&<place>`,
/// `&mut <place>` 등). `place_expr`에서 가장 안쪽의 역참조의 타입이 `Self`가 되고,
/// X 타입은 타입 매개변수를 추론에 맡긴 `SmartPtr<_>`가 됩니다. `X::Target == P::Target`
/// 제약을 `<place_expr>`의 타입으로부터 사용할 수 있습니다. `<place_expr>`에 역참조가
/// 없다면, 이를 `LocalPlace<S>`(아래 정의)를 역참조하는 것으로 간주합니다.
///
/// Safety: `borrow`는 `**self`를 `p.offset()`만큼 오프셋팅한 place를 가리키는
/// 새로운 place 컨테이너를 구성해야 합니다. `**self`의 그 밖의 바이트에는
/// 접근해서는 안 됩니다(그 바이트는 대여 중이거나 초기화되지 않았을 수 있음).
unsafe trait PlaceBorrow<'a, P, X>
where
P: Projection,
Self: HasPlace<P::Source>,
X: HasPlace<P::Target>
{
/// Safety: `'a` 동안 `p`는 `**self` place에 대해 유효한 투영이어야 합니다.
/// 이에는 `X::BORROW_KIND`가 기술하는 별칭 제약을 준수하는 일도 포함됩니다.
unsafe fn borrow(*const self, p: P) -> X;
}
// 기본 동작들.
impl<P> PlaceBorrow<'a, P, &'a P::Target>
for &'a P::Source
where P: Projection
{ ... }
impl<P> PlaceBorrow<'a, P, &'a mut P::Target>
for &'a mut P::Source
where P: Projection
{ ... }
impl<P> PlaceBorrow<'a, P, &'a P::Target>
for &'a mut P::Source
where P: Projection
{ ... }
// 기본 `Deref` 동작.
impl<P> PlaceBorrow<'a, P, &'a P::Target>
for Arc<P::Source>
where P: Projection
{ ... }
// Field Projections 이니셔티브에서 원했던 재미있는 것들.
impl<P> PlaceBorrow<'_, P, ArcRef<P::Target>>
for Arc<P::Source>
where P: Projection
{ ... }
impl<P, T> PlaceBorrow<'a, P, &'a Rcu<T>>
for &Mutex<P::Source>
where P: Projection<Target=Rcu<T>>
{ ... }
// 공유 재대여가 가능한 포인터라면 포괄적으로 `Deref`를 구현합니다.
impl<T> Deref for T
where
T: HasPlace
T: for<'a> PlaceBorrow<'a, empty_projection!(T::Target), &'a T::Target>
{
type Target = <T as HasPlace>::Target;
fn deref(&self) -> &Self::Target { &**self }
}
impl<T> DerefMut for T { ... } // 동일한 논리
/// place에 쓰기. 문법: `<place_expr> = something();`.
trait PlaceWrite<P: Projection>: HasPlace<Target=P::Source> {
/// 연산이 안전한지 여부.
const SAFE: bool;
/// Safety: 별칭이 올바르게 강제되는 등 안전 요구사항을 만족해야 합니다.
unsafe fn write(*mut self, p: P, x: P::Target);
unsafe fn write_from(*mut self, p: P, ptr: *const P::Target);
}
/// place에서 읽기. 예: `let x = <place_expr>`, 혹은
/// `something(<place_expr>)`.
/// 읽기는 복사 또는 이동일 수 있으며, 스마트 포인터는 그 차이를 관찰하지 않습니다.
/// 대신 이동은 `PlaceMove`가 구현된 경우에만 허용되고, 대여 검사기가 이를 보장합니다.
trait PlaceRead<P: Projection>: HasPlace<Target=P::Source> {
/// 연산이 안전한지 여부.
const SAFE: bool;
/// Safety: 별칭이 올바르게 강제되는 등 안전 요구사항을 만족해야 합니다.
unsafe fn read(*const self, p: P) -> P::Target;
unsafe fn read_to(*const self, p: P, ptr: *mut P::Target);
unsafe fn read_discriminant(*const self, p: P) -> P::Target::Discriminant;
}
/// 스택 로컬에서 빌릴 때 사용하는 place 래퍼. 예:
/// ```rust
/// impl Foo { fn method(self: MyPtr<Self>) { ... } }
/// let x: Foo = ...;
/// x.method();
/// // 디슈거하면 다음과 같습니다.
/// Foo::method(@MyPtr(x))
/// // 이는 `impl PlaceBorrow<P, MyPtr<U>> for LocalPlace<T>`로 이어집니다.
/// ```
/// 아래의 고아 규칙(orphan rules) 논의 참고.
#[repr(transparent)]
pub struct LocalPlace<T>(T);
impl<T> HasPlace<T> for LocalPlace<T> { ... }
대여 검사 관점에서 값을 이동해 꺼내는 것은 어렵지 않습니다. 연산적으로는 포인터 읽기이며, 읽힌 값은 부분 이동된(partially moved-out) 상태로 남습니다. 드롭 전개(drop elaboration)는 값의 나머지 부분을 적절히 드롭하도록 보장할 수 있습니다.
그렇다면 남는 것은, 예컨대 T가 이동된 상태의 Box<T>처럼 여전히 정리(예: 메모리 해제)가 필요하거나 다시 채워야 하는, “무효 상태”의 포인터입니다. Benno의 아이디어를 차용하면 다음과 같을 수 있습니다:
/// place에서 이동을 허용하는 place 컨테이너. 실제 이동은 `PlaceRead`로 수행합니다.
/// `DropHusk`가 구현되어 있지 않다면, 대여 검사기는 스코프 종료 전까지 이동된
/// 서브 place에 새 값을 반드시 써 넣도록 요구합니다.
// 이 트레이트가 `P: Projection`을 받도록 하여, 사용자가 특정 타입으로만 이동을
// 제한할 수도 있습니다.
trait PlaceMove {}
/// 이동 또는 `BorrowKind::Owned` 대여를 허용하는 place 컨테이너. 만약 place의
/// 어떤 부분이 이동된 상태라면, 드롭 전개는 나머지를 드롭하고 최종 정리를 위해
/// `drop_husk`를 호출하도록 만듭니다.
trait DropHusk: HasPlace {
/// Safety: `self`는 `Self`의 유효하지만 안전하지 않은 값(이 place의 서브 place를
/// 읽거나 드롭하여 얻은 상태)을 가리킵니다.
unsafe fn drop_husk(*mut self);
}
fn foo(x: MyPtr<Foo>) {
drop(x.a);
}
// 드롭 전개 후:
fn foo(x: MyPtr<Foo>) {
drop(x.a);
core::mem::drop_in_place(&raw mut x.b);
(&raw mut x).drop_husk();
}
포인터가 *mut 재대여를 지원하지 않는다면 대신 drop(x.b)를 할 수 있습니다(먼저 값을 이동해 꺼낸 다음 드롭).
이는 일부 값을 PlaceRead로 이동해 꺼낸 다음 다른 값을 PlaceWrite로 다시 써 넣는 경우도 매끄럽게 지원합니다. 대여 검사기는 끝에 전체 값이 되거나, 아니면 모든 것이 적절히 드롭되도록 보장합니다.
진정한 일급을 위해, 커스텀 place도 &mut처럼 재대여를 지원해야 합니다:
fn foo(x: MyMutPtr<Foo>) {}
let x = ...;
foo(x);
foo(x);
&mut 재대여와 같은 메커니즘을 쓰면 충분히 쉬워 보입니다. 즉, 컴파일러가 &mut 재대여를 삽입하는 곳마다 커스텀 place에도 동일하게 적용합니다. 예컨대 여기서는 첫 번째 foo(x)가 foo(@MyMutPtr *x)가 될 것입니다.
재대여에 관한 중요한 포인트: https://haibane-tenshi.github.io/rust-reborrowing/ . 우리의 제안은 여기에 부딪히지 않습니다. 타깃 수명은 대여 검사기가 부여하며, 소스 수명과 트레이트 시스템 수준의 관계가 없습니다. 올바른 관계는 대여 검사기가 강제하며, 그 결과가 정확히 동작한다고 생각합니다. 혹시 관계가 필요할 수도 있겠지만, 문제의 블로그 글에서처럼 바깥쪽 &mut가 존재하지 않습니다.
impl<T, P: Projection> PlaceBorrow<'a, P, MyMutPtr<'a, P::Target>> for MyMutPtr<'_, T> { ... }
하지만 이 제안은 Reborrow 프로젝트 목표와 긴장 관계에 있습니다. 그들은 place 같은 것보다 훨씬 많은 경우를 지원하고자 합니다:
fn foo(x: Option<&mut Foo>) {}
let x = ...;
foo(x);
foo(x);
그들의 재대여는 명시적으로 “추가된 수명 분석을 동반한 메모리 복사”를 지향하는 반면, 우리는 커스텀 코드를 실행합니다.
두 아이디어 사이에는 약간의 임피던스 미스매치가 있습니다. “수명 분석만”의 관점은 대부분의 타입에 유용하고 합성 가능합니다. 우리가 제안한 방식은 지금까지 구축한 전체 구도에 자연스럽지만, place 같은 것에만 유효합니다.
그리고 Option<&mut Foo>가 자동 재대여가 가능하다면, Option<MyMutPtr<Foo>>도 당연히 원하게 됩니다! 하지만 그 경우에는 포인터가 Rc 기반이라면 카운팅 증가 같은 코드를 실행해야 합니다.
주목할 점(고마워요, Benno!)은 이것이 참조 카운팅 인퍼런스(ergonomic-ref-counting) 제안과 상호작용한다는 것입니다. 이 난제를 자르는 한 방법은, 투영 재대여가 아무 코드도 실행하지 않음을 보장하는 unsafe trait TrivialReborrow를 도입하고, 자동 재대여를 그런 place에만 허용하는 것입니다. 이렇게 하면 Reborrow 제안과도 호환될 것입니다.
명확하지 않은 부분이 하나 있습니다. P<Q<T>>에서 **x는 어떨까요? 예: MyPtr<&T>.
첫 번째 포인트는, 여기서 Q<T>가 Copy가 아니라면 값을 얻을 수 없다는 것입니다. 컴파일러가 만든 unsafe 코드라도, Cell 같은 것을 담고 있다면 깨지게 됩니다.
그래서 저는 다음을 상상합니다:
let x: P<Q<Foo>> = ...;
let a = @R (**x).a;
// `**x`는 `Q`-종류의 place이므로, 아마도 `impl PlaceBorrow<P, R<A>> for Q<Foo>`를
// 사용해야 합니다. 그러면 `*const Q<Foo>`가 필요해집니다. 자명한 디슈거는:
let _tmp: *const Q<Foo> = &raw const *x;
let a = <_ as PlaceBorrow<..>>::borrow(_tmp, proj_type!(Foo.a));
이로써 *const 재대여가 꽤 중심적이 됩니다. Q<Foo>: Copy라면 PlaceRead만 필요하니 더 좋습니다. Copy를 좀 더 완화할 수도 있는데, &mut를 읽어오는 건 아마 괜찮을 겁니다. 여기서 무엇이 최선일지는 확신이 없습니다.
어쩌면 약간 과할 수도 있는 대안은 트레이트로 커스텀 동작을 두는 것입니다. 사실 어떻게 동작해야 할지 모르겠습니다. 매치 인체공학(match ergonomics)의 “&&mut T가 &T가 되는” 동작을 트레이트로 인코딩할 수 있지 않을까 은근히 바라고 있습니다. 너무 멀리 가기 전에 누가 좀 말려주세요 x)
/// 현재 place에 담긴 포인터를 역참조합니다.
trait PlaceDeref<P, X>
where
P: Projection,
Self: HasPlace<Target: HasPlace>, {
// uhhh
}
패턴 매칭은 place를 기반으로 하며, 커스텀 place에도 적용할 수 있습니다!
fn foo(x: MyPtr<Option<Foo>>) {
match *x {
Some(ref foo) => ...,
None => ...,
}
}
// 컴파일되면 대략 다음과 같습니다:
fn foo(x: MyPtr<Option<Foo>>) {
let d = (&raw const x).read_discriminant(empty_projection!(Option<Foo>));
match d {
Some => {
let foo = &(*x).Some.0;
...
}
None => ...,
}
}
첫 번째 질문은 패턴에서의 커스텀 대여 문법입니다. 같은 @MyPtr을 쓰는 것도 상상할 수 있습니다. 예: Some(@MyPtr foo). 완전히 만족스럽지는 않지만, 바이크셰드에 열어 둡니다.
두 번째 질문은 매치 인체공학입니다. 다음은 어떻게 되어야 할까요?
fn foo(x: MyPtr<Option<Foo>>) {
match x {
Some(foo) => ...,
None => ...,
}
}
주장하자면, 자동으로 let foo = @MyPtr x.Some.0를 해 줄 수도 있겠습니다. 하지만 x: &MyPtr<Option<Foo>>이면? x: MyPtr<&Option<Foo>>이면? 또는 물론 x: Pin<&mut Option<Foo>>이면? 아직 좋은 답을 모르겠습니다.
제 첫 직감은 “가장 안쪽 포인터 타입을 유지하자”입니다. x: &MyPtr<Option<Foo>>라면 &raw const *x: *const MyPtr<..>를 사용해 MyPtr<Foo>를 얻는 식입니다. 일반적으로도 이게 말이 되는지는 모르겠습니다… 위의 이중 역참조 논의와도 연관된 느낌입니다.
조금 건너뛰었던 부분이 있습니다. MyPtr<A, B, T>처럼 여러 제네릭 매개변수를 갖는 타입으로 빌리고 싶으면? 혹은 Pin<&mut T>? 또는 &mut MaybeIninit<T>?
원칙적으로 문제는 없습니다. 올바른 PlaceBorrow 구현만 있으면 됩니다. 다만 대여 문법이 고민입니다. @<Pin<&mut _>> place? 조금 아쉽네요.
프로젝션 대상에는 Cell, MaybeUninit, ManuallyDrop, RefCell처럼 간접 참조가 없는 컨테이너도 포함됩니다. 이들이 여기에 어떻게 들어맞는지는 아직 충분히 고민하지 않았습니다.
어려운 점은 이들이 보통 스마트 포인터와 결합되어 사용된다는 것입니다. 예를 들어 MyPtr<MaybeUninit<Foo>>는 MyPtr<MaybeUninit<Field>>로 투영될 수 있어야 합니다. 이것을 올바르게 생각하는 방법은 MaybeUninit<Foo>가 개념적으로 MaybeUninit<Field> 타입의 필드를 갖는다고 보는 것입니다(즉, MyPtr<MaybeUninit<_>>를 새로운 스마트 포인터로 취급하지 않음).
동시에 MaybeUninit: HasPlace는 충분히 의미가 있습니다. 여기에 더 생각할 여지가 있습니다. Field Projection 분들이 이 부분에 대해 많은 생각을 하셨던 것으로 압니다.
문법적으로는 MaybeUninit 등이 place에서 place로의 연산으로 동작하는 것이 마음에 듭니다. 예: &mut MaybeUninit(*x). 어쩌면 이쪽은 IsPlace일지도요.
Rust의 place 프로젝션에는 필드 투영뿐 아니라 인덱싱도 포함됩니다! 사실, 대여 검사기는 상수 인덱스를 추적할 수 있습니다. 다만 슬라이스 패턴에서만 관찰할 수 있습니다:
fn foo(mut x: Box<[u32]>) {
let [ref mut a, ..] = *x else { return };
let [_, ref mut b, ref mut rest @ ..] = *x else { return };
*a = 0;
*b = 0;
}
// MIR는 대략 다음과 같이 나옵니다:
fn foo(mut x: Box<[u32]>) {
if x.len() <= 1 { return }
let a = &mut (*x)[constant 0];
if x.len() <= 2 { return }
let b = &mut (*x)[constant 1];
*a = 0;
*b = 0;
c.write_with(|_| 0);
}
대여 검사기는 사용자 작성 인덱싱에 대해서는 거부하면서도, 여기서는 두 대여가 서로 분리되어 있음을 알아낼 수 있습니다.
우리의 목적에서는, 진정한 일급 지원을 위해 인덱싱 프로젝션이 필요하다는 뜻입니다. 그래서 Projection::offset이 연관 상수가 아니라 메서드인 것입니다. 인덱싱 프로젝션은 인덱스를 담아야 하니까요.
큰 설계 영역입니다. 필드 단위로 한다면 훨씬 단순해지기도 합니다. 자세한 내용은 관련 논의를 참고하십시오.
unsized 타입에는 추가적인 복잡성이 있습니다. 그 타입에 대한 포인터를 만들기 위한 메타데이터가 필요합니다. 대부분의 경우, 재대여는 같은 메타데이터를 그대로 유지합니다. 예: &mut ManuallyDrop<dyn Trait>에서 &mut dyn Trait로.
하지만 구간 인덱싱(&x[i..j])에서는 새 메타데이터를 사용자가 제공합니다. 그래서 Projection에는 metadata 메서드가 있습니다. 그런 다음 HasPlace::metadata는 필요할 때 초기 메타데이터를 얻는 데 사용됩니다. 예컨대 Box<[T]>에서 길이를 얻는 경우 등입니다.
제안된 트레이트들은 모두 매우 unsafe합니다. 경우에 따라 이를 안전하게 구현할 수 있을까요?
답: 불가능하다고 봅니다. 동시 대여를 표현하려면 unsafe가 필요합니다. 다른 대여가 살아 있는 동안 스마트 포인터는 본질적으로 안전하지 않은 상태가 되기 때문입니다.
사실 안전한 버전은 이미 Deref/DerefMut의 형태로 존재합니다. 앞서 본 것처럼 이들은 허용 가능한 별칭 수준에 근본적인 한계가 있습니다.
안전 요구사항은 여전히 작업 중입니다. 대여 검사와의 상호작용도 더 많은 작업이 필요합니다.
이 제안은 사용성 비용이 큽니다. 저는 래퍼 구조체 등에 종종 Deref/DerefMut를 구현합니다. 하지만 보다 미세한 별칭을 얻기 위해 커스텀 place 투영을 사용하면, 다음과 같은 방대한 unsafe 구현이 필요합니다:
struct Data { ... }
struct WrappedData {
data: Data,
...
}
impl HasPlace for WrappedData {
type Target = Data;
const BORROW_KIND: BorrowKind = BorrowKind::Owned;
fn metadata(*const self) {} // `Data`는 sized
}
impl<P> PlaceBorrow<'a, P, &'a P::Target> for WrappedData
where P: Projection<Target=Source>
{
const SAFE: bool = true;
// Safety: ...
unsafe fn borrow(*const self, p: P) -> &'a P::Target {
// Safety: ...
unsafe {
<&Data as PlaceBorrow<'a, P, &_>>::borrow(&raw const self.data, p)
}
}
}
impl<P> PlaceBorrow<'a, P, &'a mut P::Target> for WrappedData
where P: Projection<Target=Source>
{ /* 동일 */ }
이 구현들로, 감싸진 Data의 필드들을 동시에 빌릴 수 있습니다:
let a = &mut wrapped_data.data_field1;
let b = &mut wrapped_data.data_field2;
다만 WrappedData 자체의 다른 필드를 빌리는 것과 이를 결합할 수는 없습니다. place에서 유도된 일부 대여가 살아 있는 동안에는, 그 포인터는 다른 place-유도 연산을 제외하고는 접근할 수 없습니다.
이 고통을 감수해야 할 것 같습니다. unsafe가 필요하다는 점은 이미 확인했습니다. 타입 변경 재대여와 대여 검사 추적 동시 대여를 원한다면 본질적인 복잡성이 따릅니다.
만약 다중 레벨 투영에 대한 마음을 바꾼다면, 사용성은 좀 더 나아질 수 있습니다.
packed 구조체는 참조를 취할 수는 없지만 읽고 쓸 수 있는 필드를 갖는다는 점에서 재미있습니다. 이 제안에서 그런 필드들은 읽기/쓰기는 가능하지만 항상 대여할 수 있는 것은 아닌 place가 됩니다. 기본적으로, 정렬되지 않은(unaligned) 읽기를 지원하는 포인터만이 그러한 필드를 대여할 수 있어야 합니다.
질문은 packed 구조체의 필드가 일반적인 투영처럼 동작할 수 있는가입니다. 제 생각에는 가능하며, 대여 검사기는 그러한 place에서 PlaceRead/PlaceWrite는 허용하되 PlaceBorrow는 허용하지 않을 것입니다. 아니면 MaybeUnalignedProjection 같은 트레이트가 필요할 수도 있겠습니다.
반복적으로 등장하는 기능 아이디어로 뷰 타입(view types)과/또는 부분 빌림(partial borrows)이 있습니다.
뷰 타입에 대해서는, 새로운 종류의 투영으로 생각할 수 있습니다. 예컨대 MyPtr<Data>에서 {field1, field2} Data로의 MyPtr 투영.
부분 빌림은 잘 모르겠습니다. 부분성(partiality)이 참조의 일부일까요? 아니면 수명의 일부일까요?
여기 SoA를 활용한 스케치가 있습니다(특정 프로젝션 검사 방식이 있다고 가정):
struct Foo {
a: A,
b: B,
}
struct SoAFoo {
a: Vec<A>,
b: Vec<B>,
}
impl HasPlace for SoAFoo {
type Target = [Foo];
}
impl SoAFoo {
pub fn idx(&self, idx: usize) -> SoAElem<'_> {
assert!(idx < self.a.len());
SoAElem { soa: self, idx }
}
}
struct SoAElem<'a> {
soa: &'a SoAFoo,
idx: usize,
}
impl HasPlace for SoAElem<'_> {
type Target = Foo;
}
// 전체 `Foo` 읽기
impl<P: Projection> PlaceRead<ProjectBase<Foo>> for SoAElem<'_> {
unsafe fn read(*const Self, p: ProjectBase<Foo>) -> Foo {
Foo { a: self.soa.a[self.idx], b: self.soa.a[self.idx] }
}
}
// 빈 투영에 대한 `PlaceWrite`도 구현하지만, `PlaceBorrow`는 구현하지 않음.
// `Foo.a` 서브 place로의 포인터 얻기
impl<P: Projection> PlaceBorrow<'_, ProjectChain<frt!(Foo, a), P>, *mut P::Target> for SoAElem<'_> {
unsafe fn borrow(*const Self, p: ProjectChain<frt!(Foo, a), P>) -> *mut P::Target {
let ProjectChain(_proj_a, proj_tail) = p;
<&A as PlaceRead<P>>::borrow(&raw const self.soa.a[self.idx], proj_tail)
}
}
// `Foo.b`도 동일
impl<P: Projection> PlaceBorrow<'_, ProjectChain<frt!(Foo, b), P>, *mut P::Target> for SoAElem<'_> {
// 동일
}
// 이 둘을 이용해 다른 대여뿐 아니라 읽기/쓰기 구현도 가능.
// 인덱싱 투영 이후에는 `SoAElem`에서 허용되는 모든 투영을 `SoAFoo`에서도 허용.
// 주: `indexing_proj!(Foo): ProjElem<Source=[Foo], Target=Foo>`.
impl<'a, P, X> PlaceBorrow<'a, ProjectChain<indexing_proj!(Foo), P>, X> for SoAFoo
where
P: Projection,
SoAElem<'_>: PlaceBorrow<'a, P, X>
{
unsafe fn borrow(*const Self, p: ProjectChain<...>) -> X {
let ProjectChain(idx_proj, proj_tail) = p;
let idx = idx_proj.offset / size_of!(Foo);
<_ as PlaceBorrow>::borrow(&raw const self.get(idx), proj_tail)
}
}
// `PlaceRead`와 `PlaceWrite`도 동일하게 위임
// TODO: 구간 인덱싱은?
#[test]
fn test() {
let soa: SoAFoo = ...;
let elem: SoAElem = soa.get(0);
// 메모리에 실제 Foo가 없으므로 빌릴 수는 없지만, 읽고 쓸 수는 있습니다.
let foo: &Foo = &*elem; // 오류
let foo: Foo = *elem; // OK
*elem = Foo::new(); // OK
// 필드에 대해서는 무엇이든 가능합니다.
let a = &elem.a; // 동작
let aa = &elem.a.blah; // 동작
}
&own 참조이 제안은 소유 참조(owning reference)를 인체공학적으로 제공합니다. 이는 값을 소유하고 드롭할 책임을 지지만, 할당 자체는 소유하지 않는 참조입니다.
struct Own<'a, T>(*const T, PhantomData<&'a T>);
impl HasPlace for Own<'_, T> {
// 이는 `Own`으로의 재대여가 대여 검사기 관점에서 이동으로 취급된다는 뜻입니다.
// 즉, 그 place에 대한 다른 접근은 허용되지 않습니다.
const BORROW_KIND = BorrowKind::Owned;
..
}
// 대여 검사기가 우리에게 `'a`를 주고, 대여 지속 시간을 아는 데 사용합니다.
impl PlaceBorrow<'a, P, Own<'a, P::Target>> for Box<P::Source> { ... }
impl PlaceRead<..> for Own<..> { .. }
impl PlaceMove<..> for Own<..> { .. }
// 이제 다음과 같이 쓸 수 있습니다:
let b: Box<Foo> = ...;
let own_a: Own<'_, A> = @Own b.a;
b.a = another_a(); // 오류: 해당 place가 대여 중
let a = *own_a; // 값을 읽고, 이어서 `own_a`에 대해 `PlaceMove::drop_husk` 호출
let _ = &b.a; // 오류: 해당 place가 이동됨
use(b); // 오류: b의 일부가 이동됨
b.a = another_a(); // OK
// 이제 `b`는 다시 정상입니다.
let own_a: Own<'_, A> = @Own b.a;
// 여기서 `b.a`는 이동된 것으로 간주되므로, 함수 끝에서 `b.other_field`가 있다면
// 드롭되고, `b`에 대해 `PlaceMove::drop_husk`가 호출됩니다.