인자를 둘러싼 논쟁

코딩 에이전트가 코드를 작성하면서, Steve Klabnik의 Rust 이름 있는 매개변수 도입에 대한 오랜 반대가 조건부 수용으로 바뀜. 직접 입력하는 부담은 줄고 호출부의 명확성은 여전히 가치가 있음 이름 있는 인자는 같은 타입의 값 여러 개를 전달할 때 각 값의 역할을 드러냄. 에이전트도 함수 정의를 조회하지 않고 의미를 파악할 수 있지만, 토큰과 호출 절감 효과는 아직 실제 평가로 검증하지 않음 선택적 인자와 기본값 인자에는 여전히 반대함. 입력량을 줄이는 대신 호출부에서 실제로 전달되는 값을 숨기며, 에이전트가 작성할 때는 입력량 절감의 이점이 약해짐 Rust의 서로 다른 함수 이름과 빌더 패턴은 언어 규칙을 단순하게 유지하는 대안임. 다만 빌더도 장황하고, 선택적 인자나 기본값을 흉내 내면서 호출부의 명확성을 떨어뜨릴 수 있음 Rust에 실제로 도입할지는 별개 문제임. 패턴 기반 매개변수, 함수 포인터와 트레이트의 이름 일치, 평가 순서와 소유권, 매개변수 이름 변경의 호환성 문제를 해결해야 함 유연한 인자 API와 명확성의 대가 함수 정의의 x, y는 매개변수(parameter) 이고, foo(5, 6)에서 전달하는 5, 6은 인자(argument) 임 Rust에는 매개변수와 인자를 다루는 복잡한 기능이 많지 않지만, Ruby의 Rails redirect_to는 매우 다양한 호출 방식을 지원함 URL 문자열이나 모델 인스턴스를 전달하거나, action: "show", id: 5처럼 동작을 지정할 수 있음 모델 URL과 함께 alert, HTTP 상태 코드인 status, flash 등을 전달할 수도 있음 이런 API는 간결하고 아름다울 수 있지만, 함수가 무엇을 할 수 있는지 파악하기 어려워 좋은 문서에 크게 의존함. Rails의 문서는 좋은 편이지만 모든 라이브러리에 같은 수준을 기대할 수는 없음 이 문제에는 유연한 인자 타입, 옵션 해시, 기본값, 키워드처럼 보이는 문법이 함께 얽혀 있음. 이름표가 붙은 인자 하나보다는 이런 API 스타일 전체가 회의적인 태도의 출발점임 이름 있는 매개변수의 장점과 중복 이름 있는 매개변수를 지원하면 foo(5, 6) 대신 foo(x: 5, y: 6)처럼 호출할 수 있음. 일부 언어는 foo(y: 6, x: 5)처럼 인자 순서를 바꾸는 것도 허용함 호출부에 이름이 있으면 값의 의미가 더 분명해짐. FastAPI의 status_code=200은 숫자 200만 전달...