`Handle` 트레이트 제안에 대한 피드백을 정리한다: `Clone`까지 아우르는 편의성과 명시성을 함께 높이는 해법의 필요성, 그리고 러스트 관례에 맞는 이름 재고. 현재는 `Share`를 선호하고 `Alias`를 차선으로 본다. 다음 글에서 더 사용성 높은 아이디어를 예고한다.
내가 제안한 Handle 트레이트에 대해 두 가지 큰 부류의 반응이 있었다. 첫째는 Handle 트레이트가 유용해 보이긴 하지만, 사람들이 편하게(clone 호출을) 하고 싶어 하는 모든 경우를 포괄하지는 않는다는 점이다. 둘째는 이름이 러스트의 트레이트 명명 관례(짧은 동사를 선호)에 잘 들어맞지 않는다는 점이다. 내 요약 답변은 (1) 그렇다, 동의한다. 그래서 Handle뿐 아니라 Clone도 인체공학적(편의적인)으로 만들기 위해 함께 노력해야 한다고 본다. 그리고 (2) 이것도 동의한다. 그래서 다른 이름을 찾는 게 좋다고 생각한다. 지금으로선 Share가 가장 마음에 들고, 차선으로는 Alias를 생각하고 있다.
Handle 트레이트에 대한 첫 번째 우려는, 이 트레이트가 그 자체로 언제 구현해야 하는지에 대한 명확한 의미론적 기준을 제공하긴 하지만, 사람들이 clone을 호출하는 것이 성가시다고 느끼는 모든 경우를 커버하지는 못한다는 점이다. 다시 말해, 우리가 Handle을 도입하고 새로운 핸들을 만드는 일을 아주 편하게 만들어 놓았는데도 clone 호출이 여전히 고통스럽다면, 적절하지 않은 경우에도 Handle을 쓰고 싶은 유혹이 생길 수 있다.
우리 lang 팀 디자인 미팅 중 하나에서 TC가 지적했듯이, 많은 애플리케이션에서는 “비싼” clone이라 해도 사실 큰 문제가 아닌 경우가 많다. 예컨대 CLI 도구 같은 걸 만들 때, 나는 문자열, 문자열 벡터, 해시맵 등등을 정기적으로 clone한다. 이걸 Rc나 Arc에 넣을 수도 있겠지만, 실제로는 상관없다는 걸 안다.
내 해법은 간단하다. Clone과 Handle 모두에 적용되는 해결책을 만들자는 것이다. 나는 핸들이 “편의적이면서도 명시적”이어야 한다고 생각하는데, 그런 제안이 필요하다면 그 해법을 clone에도 확장하자고 말하는 건 어렵지 않다.
명시적 캡처 절 글은 이미 이런 설계에 부합한다. 나는 사용자가 move(a.b.c.clone()) 또는 move(a.b.c.handle())처럼 쓸 수 있도록 의도적으로 설계를 골랐고, 따라서 두 트레이트 모두와 동일하게(혹은 동일하지 않게…) 잘 작동한다.
Handle이라는 이름은 러스트 관례와 맞지 않는다여러 사람이 Handle이라는 이름이 이런 종류의 트레이트를 위한 러스트의 명명 관례 — 짧은 동사 — 와 맞지 않는다고 지적했다. handle을 동사로 해석할 수도 있지만 그 의미가 우리가 원하는 바와 일치하진 않는다. 타당한 지적이다. 나는 Handle이라는 이름이 _핸들_을 가리키는 _명사_를 제공한다는 점 때문에 마음에 들었지만, 트레이트 이름으로는 어울리지 않아 보인다는 데에는 동의한다. 후보를 두고 많은 바이크셰딩이 있었고, 결국 Jack Huey의 원래 제안인 Share(메서드는 share)로 돌아오게 되었다. 두 번째로는 Alias와 alias를 좋아한다. 둘 다 짧고 비교적 흔한 동사다.
처음에는 Share가 너무 일반적이고 스레드 간 공유와 지나치게 연관되어 있다고 느꼈다. 하지만 곰곰이 생각해 보면, 적어도 나는 &T를 항상 공유 참조(shared reference)1라고 부르고, &T는 Share를 구현하게 될 테니, 전반적으로 잘 들어맞는 것 같다. 이 이름을 밀어붙여 준 Ariel Ben-Yehuda에게 감사를 전한다.
최근 연달아 올린 글들은 이 영역에서 이루어진 논의들을 빠르게 훑어보려는 시도였다. 아직 최종 제안서를 쓰려는 단계는 아니다 — 여기서 나올 결과물은 여러 개의 RFC가 될 것 같다.
지금 내 생각에는 Hand^H^H^H^H, 어, Share 트레이트를 추가해야 한다. 그리고 명시적 캡처 절도 도입해야 한다고 본다. 다만 명시적 캡처 절은 분명 “커널에 쓰기엔 충분히 저수준”이지만, “GUI에 쓰기엔 충분히 사용하기 쉬운” 수준이라고 생각되지는 않는다. 다음 글에서는 궁극적인 편의성과 명시성이라는 목표에 좀 더 다가갈 수 있을지도 모를 또 다른 아이디어를 살펴볼 예정이다.
&Mutex는 불변이 아니다. 그래서 나는 shared reference(공유 참조)라는 용어가 더 낫다고 본다. ↩︎