SE-0508: 배열·딕셔너리에 후행 클로저를 허용하는 스위프트 제안
SE-0508은 스위프트에서 배열과 딕셔너리 표현식 뒤에 후행 클로저를 바로 붙일 수 있게 해주는 언어 제안이다. 지금까지 일부 타입에서만 허용되던 문법을 일반 배열과 딕셔너리로 넓혀, [String] { ... } 같은 간결한 표현을 쓸 수 있게 한다. 제안 문서 기준으로 스위프트 6.4에 반영됐고, 공개 리뷰를 거쳐 채택된 상태다.
왜 이런 제안이 나왔나
기존 스위프트에서는 후행 클로저 문법이 타입에 따라 들쭉날쭉했다. 예컨대 인라인 배열 타입에서는 타입 이름 뒤에 클로저를 곧바로 붙일 수 있었지만, 정작 가장 자주 쓰는 배열과 딕셔너리에서는 같은 방식이 막혀 있었다. 그래서 클로저를 받는 초기화 구문을 쓰려면 .init을 일부러 적거나 빈 괄호를 덧대는 우회법에 기대야 했다. 이런 차이는 문법을 익히는 사람에게 혼란을 주고 코드에도 군더더기를 남긴다. SE-0508은 이 불일치를 정리해 배열과 딕셔너리에서도 똑같은 규칙이 통하도록 맞추는 데 초점을 맞춘다.
문법이 어떻게 바뀌나
핵심은 배열이나 딕셔너리 타입 뒤에 중괄호 클로저를 이어 붙일 수 있다는 점이다. 예전에는 클로저를 넘기려면 [String].init { "a" } 나 [String]() { "a" } 처럼 .init이나 빈 괄호를 끼워야 했다. SE-0508이 반영되면 이를 [String] { "a" } 만으로 표현할 수 있다. 딕셔너리도 마찬가지여서 [String: Int] { (key: "a", value: 42) } 형태가 가능해진다. 배열 리터럴 뒤에 후행 클로저를 붙여 callAsFunction을 부르는 것도 되는데, ["a", "b", "c"] { $0.uppercased() } 같은 식이다. 불필요한 괄호와 .init 호출이 빠지면서 코드가 짧아지고, 다른 곳에서 쓰던 후행 클로저 문법과 모양도 자연스럽게 맞아떨어진다.
기존 코드에 영향은 없나
대부분의 코드는 그대로 동작하지만, 짚어둘 소스 호환성 문제가 하나 있다. 결과 빌더(result builder) 안에서 배열 리터럴을 쓴 뒤 다음 줄에 중괄호 블록을 두던 코드가 대표적이다. 이전에는 그 중괄호가 배열과 별개인 표현으로 해석됐지만, 이제는 앞 배열에 딸린 후행 클로저로 읽힐 수 있다. 같은 코드가 다른 의미로 컴파일될 여지가 생기는 셈이다. 다만 제안 문서는 이런 형태가 원래도 깨지기 쉽고 실제 사용 사례가 드물다고 본다. 그래서 영향받는 범위는 좁다고 설명한다. 그렇더라도 결과 빌더를 폭넓게 쓰는 프로젝트라면 스위프트 버전을 올릴 때 해당 부분이 의도대로 해석되는지 한 번 확인해 두는 편이 안전하다.
실무에서 무엇이 편해지나
가장 큰 이점은 코드의 잡음이 줄어든다는 점이다. 클로저를 받는 사용자 정의 초기화 구문이나 callAsFunction을 자주 쓰는 코드에서 타입 뒤에 붙던 .init이나 빈 괄호가 사라지면 의도가 더 또렷하게 드러난다. 특히 여러 줄에 걸친 클로저를 넘길 때 후행 클로저 형태가 훨씬 읽기 좋다. 배열·딕셔너리와 다른 타입 사이의 문법 차이도 사라져, 새로 배우는 사람이 규칙을 하나만 기억하면 된다. 다만 이 변화는 문법을 더 편하게 다듬는 쪽이지 없던 기능을 새로 만드는 것은 아니다. 기존에도 가능하던 동작을 더 간결하게 적게 해준다고 이해하면 된다.
SE 번호는 무엇을 뜻하나
SE-0508 앞의 SE는 스위프트 에볼루션(Swift Evolution)을 가리킨다. 스위프트는 언어에 기능을 더하거나 문법을 바꿀 때 제안서를 공개하고 커뮤니티 토론과 리뷰를 거치는 절차를 두고 있다. 이때 제안마다 SE 뒤에 네 자리 번호가 붙는데, 0508은 등록 순번일 뿐 중요도를 나타내지는 않는다. 제안은 초안 작성, 공식 리뷰, 채택 또는 반려로 이어지는 단계를 밟는다. 채택으로 표시된 제안은 리뷰를 통과해 실제 구현으로 넘어갔다는 뜻이고, 어느 버전에 담기는지는 제안 문서와 릴리스 정보에서 확인할 수 있다.
언제부터 쓸 수 있나
SE-0508은 제안 문서 기준으로 스위프트 6.4에 구현됐다. 직접 써보려면 그 기능이 들어간 스위프트 툴체인이나 Xcode를 갖추면 된다. 채택된 제안이라도 정확한 반영 버전은 릴리스 사정에 따라 달라질 수 있으니, 최신 상태는 스위프트 에볼루션 제안 페이지와 각 릴리스의 변경 사항을 함께 살펴보는 것이 확실하다. 이 문법은 기존 코드를 강제로 바꾸도록 요구하지 않는다. 따라서 새 표현을 당장 도입하지 않더라도 대부분의 프로젝트는 지금처럼 그대로 유지된다.