Rust의 미래 기능

AI 요약

Kangrejos 2026에서 Josh Triplett가 Rust 프로젝트가 개발 중인 기능을 소개했습니다. 커널 개발자가 기다리는 기능뿐 아니라 타입 시스템, 문법, borrow checker, 컴파일 타임 실행과 관련한 제안도 다뤘습니다. 여러 기능은 아직 작업 중이며, 커널에서 실제로 해결할 문제를 알려주면 개발 우선순위 결정에 도움이 된다고 설명했습니다.

구조체 일부를 빌리는 view types

현재 borrow checker는 함수 안에서는 가변 참조가 구조체의 일부 필드만 다루는 상황을 알아낼 수 있습니다. 하지만 이 코드를 여러 함수로 나누면 필드별 접근 관계를 함수 사이에서 추적하지 못해 빌림 오류가 생길 수 있습니다. view types는 함수 시그니처에 접근할 필드를 명시하는 방식으로 이 문제를 다루려 합니다. 문법보다 타입 시스템과의 통합을 먼저 연구하고 있습니다. 현재 전담 인력은 한 명이며, Jana Dönszelmann은 자금 지원을 받아 전일제 개발로 전환하려고 한다고 말했습니다. 프로토타입은 내년 중 나올 수 있다고 전망했습니다.

pattern types와 선형 타입

pattern types는 값이 특정 타입에 속하면서 패턴 조건도 만족한다고 표현합니다. 예를 들어 type Errno = u32 is 0..4096;처럼 오류 번호의 범위를 나타낼 수 있습니다. Rust nightly에는 구현이 있지만 표준 라이브러리에 통합되지 않았으며, 실용적인 형태를 만들려면 작업이 더 필요합니다. 조건을 만족하지 않는 정수를 pattern type으로 바꾸려면 명시적인 검사가 필요합니다. 컴파일러는 이를 일반 정수와 별도 타입으로 취급하므로 일반 정수의 연산이 자동으로 적용되지 않습니다. 현재 제안만으로는 포인터의 정렬된 하위 비트를 태깅에 쓰는 기능도 제공하지 않습니다.

linear types와 unforgettable types는 암묵적으로 버릴 수 없는 값을 만들려는 구상입니다. unforgettable types는 std::mem::forget()으로 내부 메모리를 누수시키는 일도 막습니다. 데이터베이스 트랜잭션처럼 반드시 커밋하거나 중단해야 하는 값을 예로 들었습니다. 다만 이런 값을 스택에 둔 채 패닉이 발생하면 안전성 문제가 생길 수 있어, 패닉이 일어나지 않는 코드 구간을 보장하는 방법이 필요합니다. 관련 작업은 trait solver 개선에 영향을 받습니다.

문법 개선과 Polonius

현재 Into::into()는 trait의 타입 매개변수를 함수에 직접 전달하지 않아 turbofish로 변환 결과 타입을 지정하기 어렵습니다. 표준 라이브러리만 바꾸는 해결책을 검토 중이며, 다음 Rust edition에 반영하는 방안을 기대하고 있습니다.

제안 중인 infix 패턴 문법은 while let Some(x) = func().await 대신 while func().await is Some(x)처럼 조건식 안에서 패턴을 쓸 수 있게 합니다. 패턴에서 선언한 변수는 조건 결과가 참인 곳에서 사용할 수 있습니다. 컴파일러 실험이 진행 중이며, 기존 코드와 호환되지 않는 파싱 변경이 필요해 새 edition이 요구됩니다. 기존 matches!() 매크로는 호환성을 위해 남습니다.

Polonius는 제어 흐름에 따라 참조의 수명을 추적하는 새 borrow checker입니다. 루프나 중간 반환이 있는 코드에서 현재 checker가 유효한 프로그램을 거부하는 사례를 줄입니다. nightly에서 사용할 수 있으며, 안정화 전에는 일부 성능 저하를 해결해야 합니다. 커널은 stable과 nightly로 검사하고 있지만, 오래된 컴파일러 버전의 버그 때문에 최소 지원 Rust 버전을 올리기 전에는 모든 코드에서 일괄 적용하기 어렵습니다.

컴파일 타임 함수와 그 밖의 제안

Rust의 const 함수는 컴파일 타임과 런타임 양쪽에서 실행되므로 런타임에는 없는 컴파일러 API를 사용할 수 없습니다. 컴파일 타임 전용 함수가 생기면 컴파일러 메타데이터를 다루는 reflection API를 추가할 여지가 생깁니다. 이를 바탕으로 별도 crate나 별도 언어에 의존하지 않는 새 매크로 시스템을 구상할 수 있지만, 아직 아이디어 단계입니다. 먼저 컴파일 타임 함수의 프로토타입이 준비되어야 합니다.

그 밖에 보장된 tail call 문법, 패닉하지 않는 함수 표시, 루프 안의 match 최적화를 위한 #[const_continue], full const generics도 언급됐습니다. tail call은 Rust의 자동 자원 정리와 맞물려 구현이 간단하지 않습니다.

Reddit 반응

• @tanoshikuidomouyo — is 문법은 반대합니다. let-chain이 추가된 상황에서 비슷한 기능을 하는 문법을 더하면 학습이 어려워지고, 기존 문법과 matches!()도 계속 남아 혼란을 키웁니다. 패턴을 오른쪽에서 왼쪽으로 읽는 것이 더 불편하다는 주장도 주관적이며, 현재 문법은 Option이나 Result를 먼저 보여줍니다.
• @JoJoJet- — 변수 바인딩을 찾으려고 표현식을 훑어야 하는 점이 불편합니다. let으로 변수 선언을 왼쪽에 두면 코드를 한눈에 파악하기 쉽습니다.
• @ShantyShark — 같은 기능을 하는 문법을 둘 두기보다 기존 if let을 없애고 새 문법으로 바꾸는 편이 낫습니다. pattern types도 새 타입이나 const generics보다 얻는 이점이 제한적인지 의문입니다.
  • @panstromek — pattern types라는 이름처럼 Rust 패턴으로 표현 가능한 조건을 쓸 수 있으므로 여러 범위나 값의 조합도 표현할 수 있습니다. 다만 trait와 coherence가 어떻게 작동할지는 아직 설계 문제입니다.
  • @ShantyShark — 패턴으로 표현할 수 있어도 const 분석이 가능한 값으로 제한됩니다. 타입 이름, 모듈 간 동일성, 외부 trait 구현 같은 문제도 남아 있습니다.
  • @panstromek — 이런 질문이 안정화 전에 풀어야 할 설계 과제입니다. 현재는 niche 최적화에 쓰이는 단순한 형태가 구현돼 있습니다.
• @Key-Bother6969 — 컴파일 타임 reflection은 Rust API를 스크립트 엔진에 노출하는 일을 쉽게 만들 수 있다고 봅니다. 다만 메타데이터를 런타임에서 한데 모으는 일과 linker 의존성도 해결해야 합니다.
• @vdrnm — 코드를 함수로 추출했더니 borrow 오류가 생기는 경험이 Rust 초심자에게 좌절감을 준다며 view types를 반겼습니다.
• @Nokel81 — 구조체 view를 일반화해 여러 view를 대상으로 제네릭하게 동작하는 방법도 있으면 좋겠습니다.
• @Ok_Currency7998 — newtype으로 표현한 논리적 제약은 생성자 밖으로 나가면 rustc나 LLVM이 알지 못합니다. pattern types가 최적화에 도움이 될 수 있다고 봅니다.
• @scheimong — view types와 turbofish를 기다려 왔으며, 추론에 기대는 into()는 리팩터링 뒤 예상 타입이 바뀌어도 오류를 드러내지 않을 수 있다고 지적했습니다. is 문법에는 반대하며 Rust의 문법이 C++처럼 비대해질까 우려했습니다.

원문: LWN / 번역·요약: Trawling