Reddit

Variadic Generics Micro Survey results

Rust 가변 제네릭 설문 결과

Rust 팀이 가변 제네릭의 활용 사례를 묻는 설문에 3,300건 넘는 응답을 받아 결과를 공개했습니다. 응답자들은 튜플 길이별 매크로 구현의 한계와 복잡성을 주로 들었지만, 기능 우선순위와 문법에는 신중한 의견도 있었습니다.

에디터 노트

매크로가 튜플 크기별 구현을 반복하게 만들고, 필요한 길이에 맞추지 못해 기능을 포기하게 한다는 사례는 가변 제네릭의 실용적 근거입니다. 다만 설문은 필요성을 묻는 응답을 모았을 뿐, 기능 도입 우선순위나 구현 비용을 비교하지는 않습니다. Reddit에서도 26개 튜플 구현 경험은 공유됐지만, 한 기능의 유용성만으로 언어 복잡성을 감수할지 반론이 나왔습니다. 타입 순회와 필터링을 포함한 문법이 무엇을 생성하는지 불분명하다는 지적도 있어, 수요와 설계의 명료성은 별도 과제로 남습니다.

AI 요약

Rust 팀은 가변 제네릭(variadic generics)의 가상 기능에 관한 활용 사례를 모으려고 1년 전 설문을 진행했습니다. 3,300건 넘는 응답 중 한 문항에만 서술형 답변이 900건 들어왔습니다. 팀은 개인정보와 답변 품질을 고려해 AI 처리를 하지 않고 데이터를 직접 검토했습니다. 보고서는 수치 결과와 자유 응답에서 발견한 경향을 함께 다룹니다.

튜플 매크로의 한계

가변 제네릭이 프로젝트를 쉽게 만들었을지 묻는 문항에서 1,702명이 그렇다고 답했고, 이 중 1,025명이 구체적인 사례를 적었습니다. 튜플 크기마다 트레이트를 구현할 때 매크로로 일정 길이까지 코드를 생성하는 사례가 많았습니다. 파서 조합기, SQL 쿼리의 열과 매개변수, 다차원 텐서, Struct-of-Arrays 자료구조 등이 예로 나왔습니다. 일부는 사용자에게 필요한 튜플 길이가 기존 구현의 한도를 넘었다고 했고, 매크로 작업이 번거로워 원하는 기능을 포기하거나 Vec<Box<dyn Trait>> 같은 다른 표현을 택했다고 답했습니다. 반면 응답자 약 7명은 매크로 우회 방식으로 충분하다고 명시했습니다.

가변 매핑과 비선형 가변성

각 튜플 요소에 같은 변환을 적용하는 가변 매핑(variadic mappings) 문항에는 1,287명이 긍정 답변을 했고, 그중 344명이 서술형 답변을 남겼습니다. 답변 다수는 앞선 활용 사례와 겹쳤으며, 튜플을 다루는 매크로의 상당수가 가변 매핑으로 대체될 수 있다는 의견도 나왔습니다. 예시 문법 (...Option<Ts>)는 처음 읽을 때 무엇이 튜플인지 헷갈린다는 지적이 있었습니다. 응답자는 ...Option<Ts>보다 ...Option<Ts>와 같은 형식이 더 명확하다는 취지로, 원문 예시의 Option<...Ts> 대신 ...Option<Ts>를 제안했습니다.

비선형 가변성(non-linear variadics) 문항에서는 696명이 긍정 답변을 했고, 205명이 세부 사례를 적었습니다. 원문은 예시가 타입 목록에서 특정 조건에 맞는 요소를 거르는 동작에 치우쳐 응답을 유도했다고 인정합니다. 일부는 데이터 파이프라인이나 쿼리 빌더에서 임의 개수의 변환 단계를 다루는 구상을 제시했지만, 앞선 문항보다 가정적이고 신중한 답변이 많았습니다.

우선순위와 남은 쟁점

마지막 의견 문항에는 572명이 답했습니다. 최고 우선순위로 꼽지 않은 응답에서는 특수화(specialization)와 개선된 상수 제네릭(const generics)이 더 필요하다는 의견이 자주 나왔습니다. 회의론자들은 복잡한 언어 기능이 쌓이면 새 사용자가 Rust를 배우기 어려워질 수 있다고 우려했습니다. 원문은 전체 분위기를 신중하지만 관심 있는 상태로 정리하며, 향후 제안은 읽기 쉬운 문법과 매크로 대안보다 분명한 이점을 보여야 한다고 말합니다.

Reddit 반응

  • @InternalServerError7 — 제 사용 사례로는 eros::Result가 있습니다. 튜플을 26개 원소까지 직접 구현해야 했습니다. axum에서도 비슷한 일을 겪었습니다. 그보다 큰 튜플을 쓸 사람이 많을지는 모르겠지만, 만들 때는 가변 제네릭이 있으면 더 편하고 유연했을 겁니다. 필요할 때는 필요하지만 자주 쓰지는 않을 것 같습니다.
  • @kajaktumkajaktum — 어떤 기능이 누군가에게 유용하다는 점만으로 기능 도입을 정당화하기는 어렵습니다. 26개 원소보다 큰 튜플을 지원하기 어려운 사정은 기계적으로 이해되지만, 개발자가 기억해야 할 기본 개념의 수는 더 적어야 합니다.
  • @CouteauBleu — eros에 관한 글을 읽을 때 설문과 비선형 가변성이 떠올랐습니다.
  • @dgkimpton — 가변 제네릭은 매우 유용하겠지만 제안된 문법은 이상하고 지나치게 빽빽합니다. for option in ...self는 구조체 필드를 순회하는 것처럼 보이는데, 실제로 무엇으로 컴파일되는지 불분명합니다. 각 필드마다 루프 본문을 복제하는지, 제어 흐름을 갖춘 실제 반복문을 생성하는지 궁금합니다. impl UnwrapAll for (Option<...Ts>)도 (...Option<Ts>)처럼 써야 의미가 분명합니다. 타입 수준의 필터링을 반영하는 for T::Child 문법도 무엇을 확장하는지 이해하기 어렵습니다.

원문: Rust 블로그 / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗