인자 레이블은 Swift 함수 인터페이스의 중요한 부분이다. 인자 레이블은 함수의 특정 인자가 어떤 역할을 하는지 설명하고 가독성을 높인다. 때로는 인자에 가장 자연스러운 레이블이 in, repeat, defer와 같은 언어 키워드와 일치하는 경우가 있다. 이러한 키워드는 인자 레이블로 사용할 수 있어야 하며, 이는 인터페이스를 더 잘 표현할 수 있게 한다.
일부 함수에서 특정 매개변수의 가장 적절한 인자 라벨이 언어의 키워드와 일치하는 경우가 있다. 예를 들어, 컬렉션 내에서 특정 값의 인덱스를 찾는 모듈 범위 함수를 생각해 보자. 이 함수의 자연스러운 이름은 indexOf(_:in:)일 것이다:
indexOf(value, in: collection)그러나 in이 키워드이기 때문에, 실제로는 백틱을 사용해 in을 이스케이프해야 한다:
indexOf(value, `in`: collection)Swift에서 새로운 API를 정의할 때, 개발자들은 이상적이지 않더라도 다른 키워드가 아닌 단어(예: 이 경우 within)를 선택하는 경향이 있다. 하지만 이 문제는 “불필요한 단어 생략” 휴리스틱 하에서 Objective-C API를 임포트할 때도 발생하며, 해당 API를 사용하려면 이스케이프가 필요하다. 예를 들면 다음과 같다:
event.touchesMatching([.Began, .Moved], `in`: view)
NSXPCInterface(`protocol`: SomeProtocolType.Protocol)inout, var, let를 제외한 모든 키워드를 인자 레이블로 사용할 수 있도록 허용한다. 이는 문법적으로 세 가지 부분에 영향을 미친다:
위 예제와 같은 호출 표현식. 여기서는 괄호로 둘러싸인 표현식 목록 내에서 “<키워드> `:`“가 어떤 문법 생성 규칙에도 나타나지 않기 때문에 문법적 모호성이 없다. 이는 가장 중요한 경우다.
함수/서브스크립트/초기화 선언: 위에서 언급한 세 가지 예외를 제외하면, 키워드 뒤에는 항상 식별자, ‘:‘, 또는 ‘_‘가 오기 때문에 모호성이 없다. 예를 들어:
func touchesMatching(phase: NSTouchPhase, in view: NSView?) -> Set<NSTouch>매개변수를 도입하거나 수정하는 키워드——현재는 “inout”, “let”, “var”——는 기존 의미를 유지해야 한다. 만약 이러한 키워드를 사용하는 API를 만든다면, 여전히 백틱(`)을 사용해야 한다:
func addParameter(name: String, `inout`: Bool)함수 타입: 이는 #2보다 더 쉬운데, 매개변수 이름 뒤에는 항상 ‘:‘가 오기 때문이다:
(NSTouchPhase, in: NSView?) -> Set<NSTouch>
(String, inout: Bool) -> Void이 기능은 기존 코드에 전혀 영향을 주지 않고, 순수하게 추가적인 기능만 제공한다. 이전에는 잘못된 형식으로 작성된 코드를 올바른 형식으로 인식할 수 있게 해줄 뿐, 이미 올바른 형식으로 작성된 코드의 동작은 변경하지 않는다.
가장 기본적인 대안은 아무것도 하지 않는 것이다. Swift API는 인자 레이블에 가장 자연스러운 단어가 키워드일지라도 계속 키워드를 피할 것이다. 임포트된 API는 백틱을 계속 사용하거나 이름을 변경해야 한다. 이 대안을 선택하면 거의 200개에 달하는 임포트된 API가 API 이름을 변경하거나 호출 지점에서 백틱을 사용해야 한다.
두 번째 대안은 in에 초점을 맞추는 것이다. in은 임포트된 API에서 가장 흔히 사용되는 키워드 인자이다. 간단한 조사 결과, in은 기존 키워드와의 충돌 중 90%를 차지한다. 또한 in 키워드는 Swift 문법에서 두 곳(반복문과 클로저)에서만 사용되므로 컨텍스트에 민감하게 만들 수 있다. 하지만 이 해결책은 컨텍스트에 민감한 키워드 파싱이 더 필요하기 때문에 다소 복잡하고 일반적이지 않다.