상위 트레이트 `auto impl` 구현 - Rust 프로젝트 목표

상위 트레이트 auto impl 구현

요약

2026 목표 기간 동안 우리는 다음 항목들의 완료를 목표로 합니다.

• RFC 3851에서 규정한 핵심 언어 기능 구현. rust-lang/rfcs#3851을 참고하세요.
• 구현이 진행됨에 따라 필요한 변경을 반영할 수 있도록 정오표(errata)를 포함해 RFC를 지속적으로 업데이트.
• impl 겹침(overlapping) 문제를 해결(연관된 기능 게이트 뒤의 선택적 기능으로 제공하는 방안 포함 가능).
• supertrait_auto_impl 기능 게이트를 사용한 표준 라이브러리 트레이트 리팩터링의 현장 시험(field trial).
• RFC에 명시된 선택적 기능과 린트를 가능한 한 많이 구현.

동기

트레이트의 진화와 트레이트 계층 리팩터링은 Rust 크레이트, 특히 표준 라이브러리에서 오랫동안 이어져 온 고질적인 문제입니다. 크레이트가 진화하고 규모가 커지면, 더 풍부한 기능을 수용하기 위해 트레이트 계층을 재구성해야 할 필요가 표준 라이브러리와 더 넓은 Rust 생태계 전반에서 자주 발생합니다.

상위 트레이트 auto impl은 트레이트 진화 문제에 대한 잠재적 해결책이자 유망한 언어 기능으로 여겨져 왔으며, 하위 크레이트(downstream crates)에서의 크고 번거로운 재작성(리라이트)을 피할 수 있게 해줍니다. 본질적으로 이 기능은 연관 아이템(associated items)이 새 상위 트레이트로 이동되는 경우에 재작성을 피하게 해주는데, 이는 이 문제가 주로 다루는 흔한 시나리오입니다.

#![allow(unused)]
fn main() {
// Before refactoring

pub trait BigTrait {
    fn method_lower_level();
    fn method_higher_level();
}

// After refactoring

pub trait BigTrait: Supertrait {
    // This signals to the compiler that `Supertrait` implementation shall
    // be automatically derived with the right items, so that ...
    auto impl Supertrait;
    fn method_higher_level();
}

pub trait Supertrait {
    fn method_lower_level();
}

// ... this `impl BigTrait` continues to compile
impl BigTrait for MyType {
    fn method_lower_level() { .. }
    // because this method is resolved to `Supertrait::method_higher_level`
    // and used to derive the `impl Supertrait for MyType` automatically.
    fn method_higher_level() { .. }
}
}

현 상태

해결하려는 문제를 더 자세히 설명하세요. 이 섹션은 왜 이 특정 문제가 프로젝트 역량을 투입해 우선순위를 둘 가치가 있는지에 대한 근거를 제시합니다. 강한 ‘현 상태’ 섹션은 (a) 대상 독자를 식별하고 (b) 그들이 오늘날 겪고 있는 문제를 구체적으로 제시합니다. 때로는 변경 사항이 그 문제들을 어떻게 해결할지에 대한 개략을 여기서부터 그려보는 것이 유용할 수 있지만, 필수는 아닙니다.

상위 트레이트 auto impl은 트레이트를 리팩터링해야 하거나 트레이트 계층을 설계해야 하는 라이브러리 작성자를 대상으로 합니다. 이 활동에서 반복적으로 등장하는 주제는 트레이트의 세분화(즉, 더 작은 트레이트들)와 함께 많은 필수 impl이 따라온다는 점입니다. 이 문제는 상위(업스트림) 트레이트가 리팩터링을 받을 때 더 악화됩니다. 이는 정당한 호환성 파괴 변경(breaking change)이지만, 하위 크레이트들 또한 원래 트레이트가 더 작은 상위 트레이트들로 분해되면서 트레이트 아이템을 새로운 impl 블록으로 옮겨야 합니다. 이런 대규모 재작성은 라이브러리 작성자에게 종종 바람직하지 않은데, 이는 하위 사용자가 라이브러리를 업그레이드하는 것을 주저하게 만들 수 있기 때문입니다. 표준 라이브러리의 경우 이는 종종 변경이 에디션(Edition) 경계에서만 반영될 수 있음을 의미합니다.

다음 6개월

우리가 지향하는 “빛나는 미래”

이 목표가 이번 목표 기간을 넘어서는 더 큰 계획의 일부라면, 궁극적으로 지향하는 목표를 개략적으로 설명하세요. 또한 왜 이 목표들이 다음으로 집중하기에 논리적인 단계인지에 대한 설명을 덧붙이는 것도 가치가 있을 수 있습니다.

이 텍스트는 규범적(NORMATIVE)입니다. 즉, 팀들은 이를 검토하고 정렬(alignment)되어 있는지 확인해야 합니다. 정렬되어 있지 않다면, ‘빛나는 미래’는 “다음에 무엇을 할 수 있을까” 같은 제목으로 자주 묻는 질문으로 옮겨야 합니다.

하지만 대부분의 제안에서는 목표를 시작하기 위해 정확한 구문(syntax)에 대한 정렬이 필수는 아니며, 문제와 해결책의 전반적인 개요에 대한 정렬만 있으면 됩니다. 이는 인체공학적 개선처럼 특히 구문에 관한 목표에서는 달라질 수 있습니다.

우리는 하위 트레이트 구현에 존재하는 아이템들을 활용해 필요한 상위 트레이트 구현을 자동으로 도출(derive)할 수 있는 메커니즘을 언어에 확립하고자 합니다. 첫 단계는 모호성(ambiguity)의 위험이 없을 때, 하위 트레이트 구현 블록에서 상위 트레이트의 연관 아이템을 해당 상위 트레이트로 해석(resolution)할 수 있게 하는 것입니다.

이어 auto impl 블록을 통해 상위 트레이트 정의로부터 기본 상위 트레이트 구현을 제공할 수 있도록 합니다. 또한 구현이 겹치거나(overlapping implementation) 커스터마이징이 필요한 경우를 대비해, 하위 트레이트 사용자가 기본 상위 트레이트 구현을 명시적으로 옵트아웃(opt-out)할 수 있는 기능도 제안할 예정입니다.

팀에 대한 요청

자주 묻는 질문

---

1. 논의를 참고하세요.↩