08 · 제네릭과 some·any

제네릭과 some·any는 결국 같은 질문에 대한 서로 다른 답이다 — "이 값의 정확한 타입을 컴파일 타임에 고정할 것인가, 런타임까지 미룰 것인가." struct/class와 some/any의 큰 그림은 iOS CS 로드맵 05장에서 이미 다뤘으니, 여기서는 그 답이 메모리 레이아웃과 SIL(Swift Intermediate Language) 수준에서 실제로 어떻게 갈리는지, 그리고 각 선택의 비용을 컴파일러를 직접 열어보며 확인한다.

Q1. 실존 컨테이너(existential container)는 어떻게 생겼고, 언제 힙 박싱이 일어나는가?

원리

SE-0335 원문이 이 비용을 정확히 명시한다: "existential types require dynamic memory unless the value is small enough to fit within an inline 3-word buffer. In addition to heap allocation and reference counting, code using existential types incurs pointer indirection and dynamic method dispatch that cannot be optimized away." 즉 힙 할당·ARC뿐 아니라 포인터 간접 참조와 동적 디스패치(PWT 경유)까지, 컴파일러가 최적화로 없앨 수 없는 비용 네 가지가 함께 따라온다.

내부 동작

실제로 Xcode 26 / Swift 6.2.1에서 직접 찍어보면 숫자가 정확히 맞아떨어진다. MemoryLayout<any P>.size는 40이고, 필드 개수를 1개(8B)부터 4개(32B)까지 늘린 구조체를 any P에 담아 컨테이너의 첫 워드를 읽으면 경계가 어디서 갈리는지 보인다: 24바이트(3-word)까지는 필드 값이 그대로 버퍼에 나타나고, 32바이트(4-word)부터는 첫 워드가 필드 값과 무관한 힙 주소로 바뀐다. 같은 타입의 서로 다른 인스턴스 두 개를 동시에 살려서 비교하면 그 주소가 매번 다르다는 것도 확인되므로, 우연이 아니라 진짜 malloc 박스라는 뜻이다.

클래스 전용 프로토콜(P: AnyObject)의 existential은 이보다 훨씬 작다 — 실측 16바이트(참조 1워드 + PWT 1워드)뿐이다. 클래스 인스턴스는 이미 그 자체가 포인터라 3-word 버퍼도, 별도 VWT도 필요 없기 때문이다. 반대로 프로토콜을 합성(any P1 & P2)하면 프로토콜마다 PWT 슬롯이 하나씩 늘어 컨테이너가 커진다(실측: any P1 40B → any P1 & P2 48B).

3-word라는 숫자 자체는 임의로 정해진 게 아니라 논쟁의 결과물이다. SR-3340 포럼 스레드에서 Chris Lattner는 2-word로 줄이자고 제안했고, Michael Ilseman은 2-word 버퍼가 단일 프로토콜 existential을 4-word로 만들어 32비트 ARM의 레지스터 배정에 유리한 "sweet spot"이라 지적했지만, Arnold Schwaighofer는 이를 뒷받침할 벤치마크가 없다는 이유로 3-word 유지를 옹호했다. 그 논쟁 이후 지금(2026)까지 3-word가 그대로 이어지고 있다.

실험 · 도구

워드 수를 1~4개로 늘린 구조체를 만들어 크기와 첫 워드 내용을 직접 비교하면 경계가 눈으로 보인다.

protocol P {}
struct W3: P { let a, b, c: Int }      // 24B = 3 word, 경계값
struct W4: P { let a, b, c, d: Int }   // 32B = 4 word, 경계 초과

print(MemoryLayout<any P>.size)          // 40 (5 word, x64) — 실측
print(MemoryLayout<W3>.size, MemoryLayout<W4>.size)  // 24, 32

// 컨테이너 첫 워드를 직접 읽어 인라인 vs 박싱을 구분한다
func firstWord(_ v: any P) -> UInt {
    withUnsafeBytes(of: v) { $0.bindMemory(to: UInt.self)[0] }
}
let w3 = W3(a: 0x1111, b: 0x2222, c: 0x3333)
let w4 = W4(a: 0x5555, b: 0x6666, c: 0x7777, d: 0x8888)
print(String(firstWord(w3), radix: 16))   // "1111" — 실제 데이터가 그대로 인라인
print(String(firstWord(w4), radix: 16))   // "a251290b0" 같은, 필드 값과 무관한 힙 주소

// 두 박스를 배열로 동시에 살려두면 서로 다른 힙 주소임을 확인할 수 있다(진짜 malloc)
let boxes: [any P] = [
    W4(a: 1, b: 2, c: 3, d: 4),
    W4(a: 5, b: 6, c: 7, d: 8)
]
print(firstWord(boxes[0]) != firstWord(boxes[1]))  // true

Instruments의 Allocations 인스트루먼트로 W4 같은 큰 값을 [any P] 배열에 반복해서 담아보면 담을 때마다 힙 할당 이벤트가 찍히는 반면, W3는 아무리 반복해도 할당이 늘지 않는 걸 직접 관찰할 수 있다.

프로젝트 적용

① 이종(heterogeneous) 컬렉션이 꼭 필요해서 any를 쓸 때, 담기는 구체 타입들이 3-word를 넘는지 미리 가늠하라. 넘는다면 그 타입을 참조 타입(class)으로 바꾸는 것도 방법이다 — 클래스 existential은 16바이트로 더 작고 값 복사 자체가 포인터 복사라 박싱 비용이 없다.

protocol Shape { func area() -> Double }

// ❌ 필드가 많은 struct를 그대로 any Shape 배열에 담으면
//    항목마다 힙 박스가 생긴다(3-word 초과 시)
struct Polygon: Shape {
    let points: [Double]   // 배열 프로퍼티라 struct 자체는 작지만,
    let a, b, c, d: Double // 이 필드들까지 더하면 금방 24B를 넘는다
    func area() -> Double { 0 }
}

// ✅ 애초에 힙에 있는 참조 타입으로 만들면 existential이 16B로 고정된다
final class PolygonRef: Shape {
    let points: [Double]
    init(points: [Double]) { self.points = points }
    func area() -> Double { 0 }
}
let shapes: [any Shape] = [PolygonRef(points: [0,0,1,1])]

② 반대로 힙 박싱 자체가 문제라면, existential이 정말 필요한지부터 재검토하라. 이종 저장이 목적이 아니라면 제네릭(<T: Shape>)이나 some Shape로 바꾸는 것만으로 버퍼/박싱 문제 자체가 사라진다(Q2·Q5 참고).

// any Shape 배열은 항목마다 dispatch·잠재적 박싱 비용이 있다
func totalArea(_ shapes: [any Shape]) -> Double {
    shapes.reduce(0) { $0 + $1.area() }
}

// 같은 구체 타입만 다룬다면 제네릭이 항상 더 싸다 — 특수화되면 박싱도 dispatch도 없다
func totalArea<S: Shape>(_ shapes: [S]) -> Double {
    shapes.reduce(0) { $0 + $1.area() }
}

꼬리 질문

Q2. some과 any는 무엇이 다른가? "역제네릭(reverse generics)"이란?

원리

SE-0244의 동기는 라이브러리 저자가 Union<Rectangle, Transformed<Rectangle>> 같은 복잡한 제네릭 타입을 그대로 노출하지 않고 "Shape를 준수한다"는 사실만 노출하려는 데 있다. 원문 표현으로는 "Generics are bound by the caller, while opaque types are bound by the callee" — 제네릭 시그니처를 화살표 오른쪽에 두는 셈이라는 프레이밍이 여기서 나온다. 이후 SE-0341이 파라미터 위치에도 some P를 허용했는데, func f(_ p: some P)는 func f<_T: P>(_ p: _T)의 축약형과 동치라고 명시한다 — 이 경우는 반환 위치와 달리 호출자가 실제 인자를 통해 타입을 정한다.

내부 동작

결정적 차이는 existential과 달리 opaque 타입은 타입 정체성(type identity)을 유지한다는 것이다. SE-0244 원문: "Unlike an existential, though, clients still have access to the type identity." 그래서 컴파일러가 호출부에서 함수 본문을 볼 수 있으면(인라이닝) 구체 타입을 그대로 알아 간접비용을 없앨 수 있다.

실제로 -emit-sil로 확인하면 이 차이가 인스트럭션 레벨에서 그대로 드러난다. func makeShape() -> some Shape { Circle() }는 반환 슬롯 타입이 $*Circle로, 구체 타입 그대로 값을 만들어 넣는다. 반면 func makeShape() -> any Shape { Circle() }는 반환 슬롯이 $*any Shape이고, 그 안에 init_existential_addr %0, $Circle 인스트럭션이 등장한다 — Circle 값을 existential 컨테이너 형태로 박싱해 넣는 전용 명령이다. some 쪽에는 이 인스트럭션이 아예 없다.

실험 · 도구

-emit-sil로 같은 함수를 some/any 두 버전으로 만들어 비교하면 init_existential_addr 유무가 바로 갈린다.

protocol Shape { func draw() -> String }
struct Circle: Shape { func draw() -> String { "circle" } }

func makeShapeSome() -> some Shape { Circle() }
func makeShapeAny() -> any Shape { Circle() }

// swiftc -emit-sil 로 뽑아보면:
// makeShapeSome(): bb0(%0 : $*Circle) — 구체 타입 그대로, existential 인스트럭션 없음
// makeShapeAny() : bb0(%0 : $*any Shape)
//   %4 = init_existential_addr %0, $Circle   ← 박싱 전용 인스트럭션
//   store %3 to %4

// 파라미터 위치 some은 호출자가 타입을 고르므로 함수 값으로 참조가 안 된다
func render(_ s: some Shape) { print(s.draw()) }
// let f = render
// ❌ error: generic parameter 'some Shape' could not be inferred
//    (호출 문맥이 없으면 컴파일러가 채워 넣을 구체 타입을 못 고른다)

프로젝트 적용

① WWDC22 "Embrace Swift generics" 가이드라인 그대로: 기본은 some을 쓰고, 배열처럼 서로 다른 구체 타입을 한 컬렉션에 섞어야 할 때만 any로 바꿔라.

protocol Shape { func area() -> Double }
struct Circle: Shape { let r: Double; func area() -> Double { .pi * r * r } }
struct Square: Shape { let s: Double; func area() -> Double { s * s } }

// ✅ 항상 같은 구체 타입 하나만 돌려준다 — some으로 정체성 유지 + 특수화 가능
func makeDefaultShape() -> some Shape { Circle(r: 1) }

// ✅ Circle과 Square를 한 배열에 같이 담아야 한다 — 이종 저장은 any의 존재 이유
let mixed: [any Shape] = [Circle(r: 1), Square(s: 2)]
print(mixed.map { $0.area() })

② API 경계에서 "이 함수는 항상 같은 타입을 돌려준다"는 사실을 some으로 타입 시스템에 알려두면, 호출자 쪽에서 == 같은 동일 타입 간 연산도 안전하게 쓸 수 있다(Q3의 covariant 소거와도 연결된다).

protocol Shape: Equatable { func draw() -> String }
struct Circle: Shape { func draw() -> String { "circle" } }

func makeShape() -> some Shape { Circle() }

let a = makeShape()
let b = makeShape()
print(a == b)   // ✅ 컴파일됨 — 둘 다 실제로는 Circle이라는 걸 컴파일러가 안다
// any Shape 였다면 Equatable의 Self 요구사항이 contravariant 위치라 이 비교 자체가 막힌다(Q3)

꼬리 질문

Q3. SE-0309 이전에 associated type을 가진 프로토콜을 실존 타입으로 못 쓴 이유는? 무엇이 풀렸나?

원리

SE-0309 원문의 두 가지 예제가 이 제약의 핵심을 보여준다. protocol Equatable { static func ==(lhs: Self, rhs: Self) -> Bool }처럼 Self가 파라미터 위치(contravariant)에 있으면, any Equatable 두 값을 비교하려 할 때 "어느 concrete Self가 들어올지" 컴파일러가 보장할 수 없어 여전히 금지된다. 반대로 protocol Copyable { func copy() -> Self }처럼 Self가 반환 위치(covariant)에만 있으면, WWDC22가 "result type erasure"라 부르는 메커니즘으로 자동으로 상위 바운드 타입(예: any Copyable)으로 소거되어 안전하게 허용된다.

내부 동작

Producing 위치(반환값)와 consuming 위치(파라미터)가 정반대로 취급되는 이유는 "누가 타입을 보장하는가"에 있다. 반환값은 함수 내부가 만들어내는 것이므로 컴파일러가 최소한 "이 프로토콜을 준수하는 어떤 타입"이라는 사실만은 보장할 수 있다 — 그래서 상위 바운드로 안전하게 소거된다. 반면 파라미터는 호출자가 채워 넣는 것인데, existential 값 하나만 보고는 그 안에 어떤 concrete Self가 들어있는지 컴파일 타임에 알 수 없으므로, 같은 concrete type이어야 하는 연산(== 등)을 호출부에서 강제할 방법이 없다.

직접 실험해보면 이 비대칭이 그대로 드러난다. associated type을 반환하는 produce() -> Food 메서드는 any Animal을 통해 호출해도 문제없이 컴파일되고 결과 타입만 소거된다. 반면 any Equatable 두 값을 ==로 비교하면 "binary operator '==' cannot be applied to two 'any Equatable' operands"라는 에러가 그대로 재현된다.

실험 · 도구

producing과 consuming을 각각 직접 재현하면 어느 쪽이 허용되고 어느 쪽이 막히는지 컴파일러 에러 메시지로 바로 확인된다.

// 1) SE-0309 이후: associated type이 있어도 existential 자체는 가능
protocol Identifiable2 { associatedtype ID2: Hashable; var id2: ID2 { get } }
struct User: Identifiable2 { var id2: Int }
let value: any Identifiable2 = User(id2: 1)   // ✅ 컴파일됨

// 2) producing 위치(반환값)는 자동 소거되어 허용
protocol Copyable2 { func copy2() -> Self }
struct Doc: Copyable2 { func copy2() -> Doc { self } }
func test(_ c: any Copyable2) {
    let x = c.copy2()   // ✅ any Copyable2로 소거되어 컴파일됨
}

// 3) consuming 위치(파라미터)는 여전히 금지
let x: any Equatable = "Paul"
let y: any Equatable = "Alex"
print(x == y)
// ❌ error: binary operator '==' cannot be applied to two 'any Equatable' operands

프로젝트 적용

① 프로토콜을 설계할 때 나중에 existential(any)로 쓸 계획이라면, Self를 되도록 반환 위치에만 두어라. 파라미터에 Self를 요구하는 멤버가 있으면 그 멤버는 any를 통해서는 영원히 호출할 수 없다.

protocol Mergeable {
    func merged(with other: Self) -> Self   // other: Self ← 파라미터 위치, contravariant
}
struct Score: Mergeable {
    let value: Int
    func merged(with other: Score) -> Score { Score(value: value + other.value) }
}

func combine(_ a: any Mergeable, _ b: any Mergeable) {
    // a.merged(with: b)
    // ❌ b가 정확히 a와 같은 concrete type인지 컴파일러가 보장 못해 호출 불가
}

② consuming 위치의 멤버를 꼭 호출해야 한다면, existential을 그대로 쓰지 말고 제네릭 헬퍼로 "언박싱"하라 — 제네릭 컨텍스트 안에서는 두 값이 같은 concrete type이라는 게 타입 시스템에 보장되므로 호출이 열린다.

func combineTyped<T: Mergeable>(_ a: T, _ b: T) -> T {
    a.merged(with: b)   // ✅ 제네릭 컨텍스트에선 a, b가 같은 T임이 보장된다
}
// 호출부에서 같은 concrete type끼리만 넘기면 컴파일된다
print(combineTyped(Score(value: 1), Score(value: 2)).value)

꼬리 질문

Q4. primary associated type(SE-0346)은 무엇을 가능하게 했으며 어떤 where 절로 풀리는가?

원리

SE-0346 원문: "Protocols can declare one or more primary associated types using a syntax similar to a generic parameter list of a concrete type." 그리고 개수 제약도 명시한다: "Specifying fewer or more type arguments than the number of primary associated types is an error." 오직 프로토콜이 primary로 선언한 associated type만 꺾쇠 문법의 대상이 된다 — 나머지 associated type은 여전히 where 절로만 제약할 수 있다. SE-0358이 표준 라이브러리 핵심 프로토콜들(Sequence<Element>, Collection<Element>, Identifiable<ID> 등)에 이걸 실제로 부여했다.

내부 동작

이게 정말 순수 문법 설탕인지는 SIL로 바로 검증된다. func sumWhereClause<S: Sequence>(_ seq: S) -> Int where S.Element == Int와 func sumPrimaryAT(_ seq: some Sequence<Int>) -> Int를 각각 컴파일해 -emit-sil을 비교하면, 두 함수의 제네릭 시그니처가 <τ_0_0 where τ_0_0 : Sequence, τ_0_0.Element == Int>로 글자 하나까지 동일하게 나온다. 확장(extension)에도 같은 규칙이 적용된다: extension Collection<String>은 extension Collection where Element == String과 동치이며 실제로 컴파일해도 똑같이 동작한다.

단, SE-0358은 모든 프로토콜에 primary associated type을 붙이지는 않았다 — LazySequenceProtocol, LazyCollectionProtocol, OptionSet, AsyncSequence 등은 향후 호환성 문제를 우려해 의도적으로 제외됐다.

실험 · 도구

동치성은 코드 두 줄만 작성해도 바로 눈으로 확인된다.

func sumWhereClause<S: Sequence>(_ seq: S) -> Int where S.Element == Int {
    seq.reduce(0, +)
}
func sumPrimaryAT(_ seq: some Sequence<Int>) -> Int {
    seq.reduce(0, +)
}
// swiftc -emit-sil 실측 (Swift 6.2.1) — 제약 구조는 같지만 텍스트가 똑같진 않다.
//   where 절 버전 : <S     where S     : Sequence, S.Element     == Int>
//   some 버전     : <τ_0_0 where τ_0_0 : Sequence, τ_0_0.Element == Int>
// 명시적 제네릭 파라미터는 소스에 쓴 이름(S)을 그대로 쓰고, some 파라미터는
// 컴파일러가 붙인 익명 이름(τ_0_0)을 쓴다. 이름만 다르고 제약은 동일하므로
// SE-0346은 순수 문법 설탕이다 — SIL·ABI 어느 쪽도 바뀌지 않는다.

// any Collection<Int>: 존재하면서도 Element 타입 제약을 그대로 유지
func printAllPrimary(_ c: any Collection<Int>) {
    for x in c { print(x) }
}
printAllPrimary([10, 20, 30])

// 개수를 잘못 지정하면 컴파일 타임에 바로 걸린다
protocol MySeq<Element> { associatedtype Element; associatedtype Index }
// func f(_ s: any MySeq<Int, String>) {}
// ❌ error: protocol type 'MySeq' specialized with too many type arguments (got 2, but expected 1)

프로젝트 적용

① 팀 컨벤션이 허용한다면 새 API 시그니처는 짧은 꺾쇠 문법으로 통일하라 — 특히 any Collection<Element>는 existential이면서도 타입 안전성(Element 제약)을 동시에 얻는 유일한 조합이라 실무에서 자주 쓸 만하다.

// Int를 원소로 하는 아무 Collection이나 받되, Element 타입은 고정하고 싶을 때
func sumAny(_ c: any Collection<Int>) -> Int {
    c.reduce(0, +)
}
print(sumAny([1, 2, 3]))
print(sumAny(1...3))

② 기존 코드베이스에 where 절로 작성된 시그니처가 이미 많다면 굳이 다 바꿀 필요는 없다 — 순수 문법 설탕이라 동작이 달라지지 않으므로, 점진적으로 새 코드에서만 짧은 문법을 쓰는 것으로 충분하다.

// 이미 있는 코드 — 굳이 마이그레이션할 필요 없음
func oldStyle<C: Collection>(_ c: C) -> Int where C.Element == Int {
    c.reduce(0, +)
}
// 새로 쓸 코드만 짧은 문법으로
func newStyle(_ c: some Collection<Int>) -> Int {
    c.reduce(0, +)
}

꼬리 질문

Q5. 제네릭 특수화는 언제 일어나는가? @inlinable은 왜 모듈 경계에서만 의미가 있는가?

원리

swiftlang/swift의 OptimizationTips.rst: "The Swift compiler will emit a version of the generic function specialized to the specific type." 그리고 WMO에 대해서는: "causes the compiler to compile a module's sources all together at once. This allows the optimizer to have module wide visibility." — 즉 WMO가 주는 건 정확히 "모듈 전체를 한눈에 보는 시야"이고, 특수화는 그 시야 안에서 컴파일러가 구체 타입을 실제로 확인했을 때 일어나는 최적화다.

내부 동작

단일 파일을 -O로 컴파일해 -emit-sil을 뽑아보면, 제네릭 함수 genericSum<T: Numeric>와 별도로 ...genericSumyxSayxGSjRzlFSi_Tg5 같은 심볼이 새로 생긴다. 맹글링에 포함된 Tg5가 "generic specialization"을 뜻하는 표식이고, 이 심볼의 시그니처는 제네릭 파라미터 없이 (Array<Int>) -> Int로 완전히 구체화돼 있다 — witness table을 넘기지 않는 정적 코드다. -wmo를 켜면 실제로 쓰이지 않는 제네릭 원본은 사라지고 특수화된 버전만 남는다.

모듈 경계를 넘는 경우는 실제로 두 개의 별도 모듈(LibA, Main)을 만들어 확인할 수 있다. @inlinable 없이 정의한 genericSumPlain<T: Numeric>을 다른 모듈에서 호출하면, Main 모듈의 SIL에 여전히 function_ref genericSumPlain<A>(_:)라는 제네릭 그대로의 호출이 남는다 — 컴파일러가 LibA의 함수 본문을 볼 수 없어 특수화를 못 하는 것이다. 반면 @inlinable을 붙인 genericSumInlinable은 Main 모듈 SIL에 함수 호출 흔적조차 남지 않는다 — 본문이 통째로 인라인/특수화되어 호출 지점에 그대로 풀려버린 것이다.

실험 · 도구

같은 모듈 특수화는 파일 하나로, 크로스모듈 차이는 두 모듈을 실제로 빌드해서 비교하면 확실하다.

@inline(never)
func genericSum<T: Numeric>(_ xs: [T]) -> T {
    var total: T = .zero
    for x in xs { total += x }
    return total
}
let ints: [Int] = [1,2,3,4,5]
print(genericSum(ints))

// swiftc -O -emit-sil 로 뽑으면 원본 제네릭 함수 외에
// "...genericSumyxSayxGSjRzlFSi_Tg5" 같은 심볼이 추가로 생긴다.
// Tg5는 "generic specialization" 표식 — 시그니처가
// (Array<Int>) -> Int 로 제네릭 파라미터 없이 완전히 구체화돼 있다.
// -wmo를 추가하면 쓰이지 않는 제네릭 원본은 사라지고 특수화 버전만 남는다.

// LibA.swift (별도 모듈로 컴파일)
public func genericSumPlain<T: Numeric>(_ xs: [T]) -> T {
    var total: T = .zero
    for x in xs { total += x }
    return total
}
@inlinable
public func genericSumInlinable<T: Numeric>(_ xs: [T]) -> T {
    var total: T = .zero
    for x in xs { total += x }
    return total
}

// Main.swift (LibA를 import, -O -wmo로 컴파일)
import LibA
print(genericSumPlain([1,2,3]))       // SIL에 여전히 function_ref genericSumPlain<A>(_:) 로 남음
print(genericSumInlinable([1,2,3]))   // SIL에 호출 흔적 자체가 사라짐 — 완전히 인라인/특수화됨

프로젝트 적용

① 사내 SPM 패키지처럼 여러 모듈로 나뉜 프로젝트에서 핫 패스에 있는 작은 제네릭 유틸리티 함수는 @inlinable을 고려할 만하다. 다만 이건 함수 구현을 모듈 인터페이스에 그대로 노출하는 트레이드오프다 — 캡슐화를 일부 포기하는 대가로 크로스모듈 특수화를 얻는 것이다.

// 다른 모듈에서도 자주 호출되는 작은 제네릭 함수라면
@inlinable
public func clamp<T: Comparable>(_ value: T, in range: ClosedRange<T>) -> T {
    min(max(value, range.lowerBound), range.upperBound)
}
// ⚠️ @inlinable 함수 안에서는 그 모듈의 internal 심볼을 쓸 수 없다
//    (그러면 그 내부 심볼까지 외부에 노출해야 하기 때문) — @usableFromInline 필요

② 반대로 프로파일링 없이 라이브러리 공개 API 전체에 @inlinable을 습관적으로 붙이지 마라 — ABI 안정성과 캡슐화를 넓게 포기하는 대가에 비해, 같은 모듈 안에서는 WMO가 이미 특수화를 해주므로 실익이 없는 경우가 대부분이다.

// ❌ 같은 모듈 안에서만 쓰이는 함수에 습관적으로 @inlinable — 실익 없이 캡슐화만 넓힘
@inlinable
func internalHelper<T>(_ x: T) -> T { x }

// ✅ 같은 모듈이면 그냥 두어라 — WMO가 필요하면 알아서 특수화한다
func internalHelperPlain<T>(_ x: T) -> T { x }

꼬리 질문

Q6. 조건부 준수(SE-0143)와 @retroactive(SE-0364)는 각각 무슨 문제를 다루는가?

원리

SE-0143의 동기: "arrays of arrays of Equatable types cannot be compared (e.g., [[Int]] == [[Int]] will fail to compile) because... the arrays themselves are never Equatable." 이를 extension Array: Equatable where Element: Equatable { ... }로 해결한다. SE-0364의 동기는 근본적으로 다르다: "protocol conformances are globally unique within a process in the Swift runtime, and if multiple modules declare the same conformance, it can cause major problems for library clients." 만약 Foundation 같은 프레임워크가 나중에 동일한 conformance를 추가하면 "their application will exhibit undefined behavior, as it is indeterminate which definition of this conformance will 'win.'"

내부 동작

조건부 준수는 컴파일 타임 타입 체크로 끝나지 않는다 — 동적 캐스팅(as? P)이 조건부 준수를 만나면 "그 조건이 실제로 만족되는가"를 런타임에 한 번 더 조회해야 한다(Q5 꼬리 질문 참고). 그리고 겹치는(overlapping) 조건부 준수는 서로소로 보여도 전면 금지된다 — SE-0143 원문: "the ban extends even to multiple conformances that are 'clearly' disjoint."

@retroactive는 순전히 컴파일 타임 마커다. Swift 6 모드에서 외부 타입(예: Date)에 외부 프로토콜(예: Identifiable)을 준수시키면 컴파일러가 경고를 낸다 — 실제로 재현해보면 "extension declares a conformance of imported type 'Date' to imported protocol 'Identifiable'; this will not behave correctly if the owners of 'Foundation' introduce this conformance in the future"라는 경고와 함께 "add '@retroactive' to silence this warning"이라는 노트가 뜬다. @retroactive를 붙이면 이 경고만 사라진다 — 반면 같은 모듈에 정의한 프로토콜에 외부 타입을 준수시키는 경우는 애초에 경고 자체가 뜨지 않는다(안전하기 때문). 어느 경우든 @retroactive가 런타임에 conformance 등록 방식이나 충돌 감지 로직을 바꾸는 건 전혀 없다.

실험 · 도구

두 제안 모두 로컬에서 직접 재현하면 각자가 정확히 무엇을 바꾸는지 컴파일러 메시지로 확인된다.

struct Wrapper<T> { let v: T }
extension Wrapper: Equatable where T: Equatable {
    static func == (l: Wrapper, r: Wrapper) -> Bool { l.v == r.v }
}
let w1 = Wrapper(v: 1)
print(w1 == Wrapper(v: 1))   // ✅ Int: Equatable 이므로 성립

struct NotEquatable {}
let w2 = Wrapper(v: NotEquatable())
// print(w2 == w2)
// ❌ error: operator function '==' requires that 'NotEquatable' conform to 'Equatable'
//    note: requirement from conditional conformance of 'Wrapper<NotEquatable>' to 'Equatable'

import Foundation
protocol MyIdentifiable { var myID: String { get } }

// 외부 타입(Date) × 내 모듈 프로토콜 → 경고 없음(안전)
extension Date: MyIdentifiable {
    var myID: String { "\(timeIntervalSince1970)" }
}

// 외부 타입(Date) × 외부 프로토콜(Identifiable) → 경고 발생
extension Date: Identifiable {
    public var id: TimeInterval { timeIntervalSince1970 }
}
// ⚠️ warning: extension declares a conformance of imported type 'Date'
//    to imported protocol 'Identifiable'; this will not behave correctly
//    if the owners of 'Foundation' introduce this conformance in the future
//    note: add '@retroactive' to silence this warning

// @retroactive를 붙이면 경고만 사라진다 — 실제 충돌 위험 자체는 그대로
extension Date: @retroactive Identifiable {
    public var id: TimeInterval { timeIntervalSince1970 }
}

프로젝트 적용

① 조건부 준수를 쓸 때는 겹치는 conformance를 설계 단계에서부터 피하라 — 컴파일러가 "서로소니까 괜찮겠지"라고 봐주지 않는다.

protocol Flyable {}
protocol Swimmable {}
struct Animal<T> { let trait: T }

extension Animal: Flyable where T: Flyable {}
// extension Animal: Flyable where T: Swimmable {}
// ❌ 같은 (Animal, Flyable) 쌍에 대한 두 번째 조건부 준수 — 조건이 겹치지 않아 보여도 금지된다

② 외부 타입에 외부 프로토콜을 준수시켜야 한다면, @retroactive를 붙이기 전에 "그 프레임워크가 나중에 같은 conformance를 추가할 가능성이 정말 없는지" 먼저 스스로 확인하라 — 컴파일러는 그 확인을 대신 해주지 않는다.

import Foundation

// ✅ 애플이 향후 Identifiable 준수를 Date에 직접 추가할 가능성이 낮다고 판단했다면
extension Date: @retroactive Identifiable {
    public var id: TimeInterval { timeIntervalSince1970 }
}
// ⚠️ 하지만 이건 "내가 위험을 감수하겠다"는 선언일 뿐,
//    다른 패키지가 같은 conformance를 이미 선언해뒀는지까지 검증해주진 않는다.
//    실제로 다른 모듈이 같은 (Date, Identifiable) conformance를 선언하고 있다면
//    @retroactive 여부와 무관하게 undefined behavior다.

꼬리 질문

출처 · 참고자료