질문의 역사: 초기 버전의 Rust는 명시적인 소멸자 호출이 필요했습니다. Drop 트레이트의 도입은 자원 정리를 자동화했지만 Rust의 이동 의미론과 결합할 때 복잡성을 초래했습니다. 일부 필드만 이동되고 나머지가 남아 있는 경우, 사용 후 해제 또는 이중 드롭 버그를 방지하기 위해 드롭 순서를 신중하게 정의해야 했습니다. 언어 설계자들은 사용자 정의 Drop 구현이 이 시나리오에서 실행되는지 여부를 명시해야 했습니다.
문제: 구조체가 Drop을 구현하면 컴파일러는 안전 불변을 유지하기 위해 모든 필드에 대한 접근이 필요하다고 가정합니다(예: Mutex 잠금 해제 또는 메모리 해제). 패턴 매칭에서 일부 필드만 이동하는 경우(let Foo { a, .. } = foo), 남은 필드는 드롭되어야 하지만 사용자 정의 Drop 구현은 이동된 필드에 접근할 수 있어 정의되지 않은 동작을 초래합니다. 이는 데이터 추출에 대한 프로그래머의 의도와 소멸자가 내부 상태에 대한 전체 접근권을 가지고 실행된다는 타입의 보장 간의 충돌을 만듭니다.
해결책: 컴파일러는 Drop을 구현하는 구조체에서 필드의 부분 이동을 금지합니다. 구조체가 패턴에서 완전히 분해되지 않는 한(모든 필드를 바인딩하는 경우)입니다. 완전히 분해되면 구조체는 이동된 것으로 간주되며 Drop이 호출되지 않으며 대신 개별 필드는 선언 순서의 역순으로 드롭됩니다. Drop이 없는 타입의 경우, 컴파일러에서 생성된 드롭 코드는 남은 필드만 처리하므로 부분 이동이 허용됩니다.
struct NoDrop(String, i32); struct WithDrop(String, i32); impl Drop for WithDrop { fn drop(&mut self) { println!("Dropping: {}", self.0); } } fn main() { let no_drop = NoDrop("a".into(), 1); let NoDrop(s, _) = no_drop; // OK: 부분 이동 허용 // println!("{}", no_drop.0); // 오류: 값이 이동됨 println!("Remaining: {}", no_drop.1); // OK: 필드 1은 여전히 유효 drop(s); let with_drop = WithDrop("b".into(), 2); // let WithDrop(s, _) = with_drop; // 오류: Drop을 구현하는 타입에서 부분 이동 불가 let WithDrop(s, n) = with_drop; // OK: 전체 파괴, Drop이 호출되지 않음 println!("Moved: {} and {}", s, n); // 스코프 종료 시 필드는 개별적으로 드롭됨 }
시스템 프로그래밍 팀이 제로 복사 네트워크 패킷 파서를 구축했습니다. 그들은 원시 버퍼와 여러 메타데이터 필드(타임스탬프, 길이)를 보유하는 Packet 구조체를 정의했습니다. Packet은 버퍼를 풀에 반환하기 위해 Drop을 구현했습니다. 그들은 나중에 패킷을 처리하는 동안 로깅을 위해 타임스탬프만 추출하려고 했습니다. 이때 매칭 암에서 부분 이동을 시도했습니다.
해결책 1: Drop 구현을 제거하고 별도의 PacketHandle 래퍼를 사용하여 풀을 관리하고 Packet은 드롭 로직 없는 일반 뷰가 되도록 했습니다. 장점: 이것은 Packet 필드의 부분 이동을 허용하고 자원 관리를 데이터 접근에서 깔끔하게 분리합니다. 단점: 이는 추가 간접 계층을 도입하고 뷰가 버퍼보다 오래 살아남지 않도록 신중한 생애 관리가 필요하여 잘못 관리될 경우 안전성을 깨뜨릴 수 있습니다.
해결책 2: 부분 이동을 피하기 위해 이동 전에 타임스탬프 필드를 복제합니다. 장점: 이는 기존 구조를 최소한의 코드 변경으로 유지하는 간단한 변경사항입니다. 단점: 복제에 대한 런타임 비용이 발생합니다; 정수에는 무시할 수 있지만, 복잡한 메타데이터의 경우 상당해지며 타입 시스템의 기본적인 구조적 제약을 해결하지 못합니다.
해결책 3: 처리 함수를 재구성하여 전체 Packet의 소유권을 취득하고 전체 파괴를 통해 필드를 추출하고 필요시 풀 반환을 위해 새로운 Packet을 재구성합니다. 장점: 이 방법은 Rust의 안전 보장 내에서 엄격하게 작동하며 소유권 이전을 명시적으로 만듭니다. 단점: 이는 장황하고 버퍼가 제대로 반환되도록 신중하게 처리해야 하며, 올바르게 재구성하지 않으면 자원 누수로 이어질 수 있습니다.
팀은 자원(버퍼)과 뷰(메타데이터)를 분리함으로써 Rust의 소유권 모델과 기본적으로 일치하는 해결책 1을 선택했습니다. 이는 컴파일 오류를 즉각적으로 제거하고 자원 관리와 데이터 보기 간의 차별화를 통해 코드 가독성을 향상시키며 프로젝트의 제로 비용 추상화 요구를 유지했습니다.
왜 컴파일러는 Drop을 구현하는 타입에 대해 부분 이동을 금지하는가?
타입이 Drop을 구현하면 컴파일러는 범위의 끝에서 drop()을 호출합니다. drop() 메서드는 &mut self를 수신하므로 잠금을 해제하거나 메모리를 해제하는 것과 같은 안전 불변성을 유지하기 위해 전체 구조체에 대한 접근이 필요합니다. 필드가 부분 이동을 통해 앞서 이동되었다면 drop()은 해제된 메모리나 유효하지 않은 자원을 접근하려고 시도하여 정의되지 않은 동작을 유발할 것입니다. 모든 필드를 바인딩하도록 전체 파괴를 요구함으로써 Rust는 소멸자 코드가 절대 실행되지 않도록 보장하고, 대신 필드를 개별적으로 드롭하여 위험한 사용자 정의 로직을 우회합니다.
구조체가 패턴 매칭을 통해 완전히 분해될 때 정확한 드롭 순서는 무엇인가?
구조체가 완전히 분해될 때(e.g., let MyStruct { field1, field2 } = my_struct;), 구조체의 Drop 구현은 완전히 억제됩니다. 그런 다음 필드는 구조체 정의에서 선언 순서의 역순으로 드롭됩니다(field2 다음에 field1). 이 동작은 구조체 필드에 대한 표준 드롭 순서와 일치하지만, 중요하게도 컨테이너의 사용자 정의 소멸자를 건너뛰어 이동된 상태를 관찰하거나 안전 보장을 위반하지 않도록 합니다.
Drop이 있는 타입이 소멸자가 항등성을 보장하면 Copy가 될 수 있는가?
아니요, Rust 컴파일러는 Copy와 Drop이 상호 배타적이라는 것을 트레이트 일관성 규칙에 따라 강제합니다. 이는 소멸자의 실제 구현에 관계없이 의도된 보수적인 설계 선택입니다: drop()이 현재 비어 있거나 항등적일 경우에도 Copy를 허용하면 암묵적 비트 단위 복사를 허용할 수 있습니다. 미래의 수정으로 인해 drop()이 비항등적으로 변할 수 있으며, 이는 안전 보장을 무시하고, 컴파일러가 컴파일 시간에 일반적으로 항등성을 검증할 수 없으므로, 안전성을 위해 조합을 금지합니다.