iOYES

[SE-0520] Discardable result use in Task initializers

GREEN.1229 — Sat, 25 Apr 2026 09:58:01 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0520 — Task 이니셜라이저에서의 Discardable result 처리에 대해 정리해보겠습니다

Intro

Proposal: SE-0520
Author: Konrad 'ktoso' Malawski
Status: Accepted

Motivation

현재 아래 코드는 아무런 경고 없이 컴파일됩니다.

Task { // no warning
  try boom() 
}
print("Yay!")

간단한 예시에서는 에러를 놓쳤다는 게 명확하지만, 실제 코드베이스에서는 노이즈가 많아서 에러를 조용히 무시했다는 사실을 놓치기 쉽거든요.

이 문제는 Swift 커뮤니티에서 여러 차례 제기되었습니다.

원래 Task {} 문법은 주로 fire-and-forget 용도로 설계되었고, throw된 에러를 처리하는 경우를 충분히 고려하지 않았습니다.

이 동작은 Swift의 에러 핸들링 모델과 일관성이 없고, 에러가 조용히 무시되어 찾기 어려운 버그로 이어집니다

Detailed Design

concurrency 라이브러리는 Task.init, Task.detached, Task.immediate, Task.immediateDetached에 typed throws를 도입했습니다.

이를 기반으로 throw 타입(throws(Failure))을 인식하는 새로운 경고 메커니즘을 도입합니다.

Failure 타입이 Never가 아닌 경우에만 경고가 발생합니다.

워닝 동작은 다음과 같아요~

Task {  }
// no warning

Task { throws in ... } 
// warning: Unstructured throwing task was not used, which may accidentally ignore errors thrown inside the task [#NoUseUnstructuredThrowingTask]
// note: To silence this warning, handle the error inside the task, or store/discard the task value explicitly

Task { throws(Boom) in ... } 
// warning: Unstructured throwing task was not used, which may accidentally ignore errors thrown inside the task [#NoUseUnstructuredThrowingTask]
// note: To silence this warning, handle the error inside the task, or store/discard the task value explicitly

Task { throws(Never) in ... }
// no warning

동일한 변경사항이 모든 unstructured task 이니셜라이저에 적용됩니다.

경고를 없애는 방법

명시적으로 값을 무시하면 경고를 없앨 수 있습니다.

_ = Task { throws in ... }

혹은 실제로 값을 사용하는 것이 권장되는 방법입니다.

throw된 에러를 관찰하려면 이렇게 하면 됩니다.

let task = Task { throws in } 

let value = try await task.value // task가 실패하면 에러를 throw합니다

Source Compatibility / ABI

소스 호환성은 유지되지만, 새로운 경고가 발생할 수 있습니다.
경고는 _ = Task { try boom() }처럼 명시적으로 무시하면 됩니다.
컴파일 타임 진단 동작만 변경되므로 ABI에는 영향이 없습니다.

Alternatives Considered

아무것도 하지 않기

커뮤니티에서 충분히 오랫동안 문제로 제기되어 왔기 때문에, 제안자는 현 상태를 유지하는 건 적절하지 않다고 판단했어요.

non-throwing 이니셜라이저에서도 discardableResult 제거하기

throw하지 않는 Task는 대부분 의도적인 fire-and-forget입니다.

결과값에 관심이 있다면 이미 task를 저장하거나 즉시 await했을 테니까요.

그래서 제안자는 throw하지 않는 이니셜라이저에는 이 변경을 적용하지 않기로 했습니다.

Conclusion

작지만 굉장히 실용적인 변경입니다.

Task { try something() }처럼 작성했다가 에러를 조용히 삼키는 버그는 실제 코드베이스에서 찾기 굉장히 어렵거든요.

이번 변경으로 컴파일러가 명시적으로 경고를 내려주니, 에러 처리에 대한 개발자의 의도를 코드에 드러낼 수 있게 됩니다

Swift의 에러 핸들링 철학인 "에러는 반드시 처리되어야 한다" 와 한층 더 일관성 있게 맞춰진 변경이라고 생각합니다.

References

swift-evolution/proposals/0520-discardableresult-task-initializers.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

Pitch: Remove discardableResult from throwing task initializers

Hi everyone, continuing the effort to improve small yet valuable things in the Concurrency library, I’d like to propose an often discussed but never finished change to Task.init and friends: removing the @discardableResult when the operation is throwing.

forums.swift.org

[SE-0519] Borrow and Inout types for safe, first-class references

GREEN.1229 — Sat, 11 Apr 2026 09:55:42 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 안전한 first-class 참조를 위한 Borrow와 Inout 타입에 대해 정리해보겠습니다

Intro

Proposal: SE-0519
Authors: Joe Groff, Alejandro Alonso
Status: Active review (March 4...17, 2026)

Motivation

Swift는 함수 호출의 일부로 값에 대한 임시 접근을 제공할 수 있습니다.

inout 파라미터: 호출자가 소유한 값에 대한 임시 독점(exclusive) 접근을 받습니다. 호출된 쪽에서 파라미터를 수정하거나 현재 값을 소비(consume)할 수 있고, 호출자는 함수가 반환되면 소유권을 다시 가져옵니다.
borrowing 파라미터: 호출자로부터 값에 대한 임시 공유(shared) 접근을 받습니다. 다른 곳에서도 동시에 접근할 수 있으므로 일반적으로 값을 읽기만 할 수 있지만, 독립적인 복사본 없이도 접근이 가능합니다.

이런 종류의 참조를 함수 호출의 범위 밖에서도 로컬 변수 바인딩, 다른 타입의 멤버, 제네릭 컨테이너의 요소 등으로 사용할 수 있으면 매우 유용할 것입니다.

기존에는 클래스로 값을 박싱(boxing)하고 참조를 전달하는 방법을 썼는데, 이렇게 하면 메모리 할당, 레퍼런스 카운팅, 동적 독점성 검사 오버헤드가 발생합니다.

UnsafePointer는 당연히 unsafe하고 Swift의 고수준 의미론과 어색하게 상호작용해서 올바르게 사용하려면 굉장히 세심한 주의가 필요했거든요.

Proposed Solution

표준 라이브러리에 두 개의 새로운 제네릭 타입을 도입합니다.

둘 다 non-Escapable 타입으로 표현됩니다.

Borrow<T>

다른 값에 대한 공유 borrow를 나타내며, 대상 값을 읽을 수 있지만 소비하거나 수정할 수는 없습니다.

public struct Borrow<Value: ~Copyable>: Copyable & ~Escapable {
  @_lifetime(borrow target)
  public init(_ target: borrowing Value)

  public var value: Value { borrow }
}

Inout<T>

다른 값에 대한 독점 접근을 나타내며, Inout의 소유자가 대상 값을 수정하고 Inout 값이 활성화된 동안 독점적으로 사용할 수 있습니다.

public struct Inout<Value: ~Copyable>: ~Copyable & ~Escapable {
  @_lifetime(&target)
  public init(_ target: inout Value)

  public var value: Value { borrow; mutate }
}

두 타입의 인터페이스는 lifetime dependencies를 사용해 ~Escapable 값을 생성하고, borrow와 mutateaccessor를 통해 불필요한 제한 없이 대상 값에 효율적으로 접근합니다.

기본 사용 예시

참조는 Borrow.init 또는 Inout.init에 대상을 전달해 생성하고, value 프로퍼티로 대상 값에 접근합니다.

딕셔너리에서 키를 한 번만 조회하고 반복 수정하는 예시입니다.

func updateTotal(in dictionary: inout [String: Int], for key: String,
                 with values: [Int]) {
  // 딕셔너리에서 키를 한 번만 조회합니다...
  var entry = Inout(&dictionary[key, default: 0])

  // ...그리고 해시 테이블을 반복적으로 탐색하지 않고 반복 수정합니다
  for value in values {
    entry.value += value
  }
}

실험적인 lifetimes 기능을 사용하면 참조를 반환하는 함수도 작성할 수 있습니다.

struct Vec3 {
  var x, y, z: Double

  @_lifetime(&self)
  mutating func at(index: Int) -> Inout<Double> {
    switch index {
    case 0: return Inout(&x)
    case 1: return Inout(&y)
    case 2: return Inout(&z)
    default:
      fatalError("out of bounds")
    }
  }
}

Borrow와 Inout은 다른 non-Escapable 타입의 필드로도 사용할 수 있습니다.

// struct-of-arrays 형태의 사람 레코드
struct People {
  var names: [String]
  var ages: [Int]

  subscript(i: Int) -> Person {
    @_lifetime(&self)
    mutating get {
      return Person(name: &names[i], age: &ages[i])
    }
  }
}

// 단일 사람에 대한 mutable 참조
struct Person: ~Copyable, ~Escapable {
  var name: Inout<String>
  var age: Inout<Int>
}

또한 제네릭 파라미터로도 사용할 수 있어서, non-Escapable 타입을 지원하는 컨테이너와 래퍼에 참조를 담을 수 있습니다.

@_lifetime(&array)
func element(of array: inout [Int], at: Int) -> Inout<Int>? {
  if at >= 0 && at < array.count {
    return &array[at]
  } else {
    return nil
  }
}

Detailed Design

Lifetime dependence

Borrow와 Inout은 모두 non-Escapable 타입입니다.

생성되면 대상에 대한 lifetime dependency를 가지므로, 대상 값이 borrow 또는 독점 접근 상태를 유지할 수 있는 동안에만 사용 가능합니다.

var totals = [17, 38]

do {
  let apples = Borrow(totals[0])

  print(apples.value) // 17 출력

  apples.value += 2 // ERROR, Borrow.value는 읽기 전용

  totals[1] += 1 // ERROR, borrow 중인 `totals`를 수정할 수 없음

  print(totals[1]) // 38 출력. totals를 다시 borrow하는 건 가능
  print(apples.value) // 17 출력
}

do {
  var bananas = Inout(&totals[1])

  bananas.value += 2 // `Inout`을 통해 값을 수정 가능

  print(bananas.value) // 40 출력

  print(totals[1]) // ERROR, totals는 `bananas`가 독점 접근 중

  bananas.value += 2
  print(bananas.value) // 42 출력
}

print(totals) // [17, 42] 출력

이 동작은 Array와 span, mutableSpan 프로퍼티를 통해 접근하는 Span 또는 MutableSpan 값 사이의 상호작용과 유사합니다.

Borrow와 Inout은 각각 Span과 MutableSpan의 단일 값 버전이라고 볼 수 있거든요.

nontrivial 접근과의 상호작용

Borrow는 모든 값을, Inout은 모든 mutable 위치를 대상으로 할 수 있습니다.

get/set 쌍, yielding 코루틴 accessor, 동적 독점성 검사가 적용된 stored property, didSet/willSet observer가 있는 경우도 포함됩니다.

struct NoisyCounter {
  private var _value: Int

  var value: Int {
    get {
      print("counted \(_value)")
      return _value
    }
    set {
      print("updating counter to \(newValue)")
      _value = newValue
    }
  }
}

var counter = NoisyCounter(67)
do {
  var counterRef = Inout(&counter.value) // `counter.value` 접근 시작, "counted 67" 출력
  counterRef.value += 1
  counterRef.value += 1
  // `counter.value` 접근 종료, "updating counter to 69" 출력
}

단, Borrow와 Inout은 접근을 종료하기 위한 컨텍스트를 캡처하지 않기 때문에, nontrivial 접근에서 파생된 경우 일반적으로 lifetime을 즉각적인 호출자 너머로 확장할 수 없습니다.

@_lifetime(&target)
func noisyCounterRef(from target: inout NoisyCounter) -> Inout<Int> {
  // ERROR, formal access 밖으로 `Inout`의 lifetime을 확장하게 됨
  return Inout(&target.value)
}

struct stored property 직접 접근, 불변 class stored property 직접 접근, borrow나 mutate accessor를 통한 접근은 종료 시 코드 실행이 필요 없으므로 이 제한이 적용되지 않습니다.

Borrow의 표현 방식

Borrow<Value>는 Value 타입의 속성에 따라 포인터 표현 또는 값의 비트 복사 표현을 사용합니다.

다음 조건 중 하나라도 해당되면 포인터 표현을 사용합니다.

MemoryLayout<Value>.size가 4 * MemoryLayout<Int>.size보다 큰 경우
Value가 bitwise-borrowable이 아닌 경우
Value가 addressable-for-dependencies인 경우

Int처럼 메모리 어디에서나 동일한 의미를 갖는 타입은 bitwise-borrowable이라 포인터 없이 값으로 전달됩니다. 반면 InlineArray처럼 Span을 파생시키는 등 내부 메모리 주소에 의존하는 타입은 addressable-for-dependencies로 분류되어 포인터 표현을 사용합니다.

C, Objective-C, C++에서 import된 struct, union, class 타입은 항상 addressable-for-dependencies로 간주됩니다.

Inout의 표현 방식

inout 파라미터는 항상 주소로 전달되므로, Inout은 모든 경우에 포인터 표현을 사용합니다.

Source Compatibility / ABI

Borrow와 Inout이라는 이름을 가진 타입이 기존 코드에 존재할 수 있지만, Swift의 이름 조회 규칙상 로컬 정의 및 명시적으로 import된 이름이 표준 라이브러리보다 우선하므로 기존 코드는 그대로 컴파일됩니다.
이 제안은 additive하며 기존 코드의 ABI에 영향을 주지 않습니다.
단, 제네릭 지원에는 새로운 런타임 타입 레이아웃 기능이 필요하므로, 구버전 Swift 런타임을 타겟으로 할 때 가용성이 제한될 수 있습니다.

Future Directions

로컬 참조 바인딩 문법 (sugar): Borrow/Inout을 명시적으로 형성하는 것의 sugar로, borrow x = y처럼 참조 바인딩 문법을 도입하는 것을 고려 중입니다.
암묵적 역참조 / 멤버 포워딩: @dynamicMemberLookup이나 Rust의 Deref 트레이트처럼 value를 거치지 않고 대상 멤버에 직접 접근하는 방법도 검토 중입니다.
~Escapable 대상 타입 지원: 현재는 대상 타입이 Escapable이어야 한다는 제약이 있는데, 컴파일러 구현 한계로 인한 것으로 향후 개선될 수 있습니다.
exclusive 소유권 또는 reborrow: var 바인딩 없이도 Inout.value를 통한 mutation이 가능하도록 하는 방법을 검토 중입니다.

Alternatives Considered

Inout 이름 짓기

일반적인 네이밍 컨벤션대로라면 InOut이 맞겠지만, 저자들은 inout이 두 단어의 조합이 아닌 하나의 키워드처럼 느껴지기 때문에 Inout을 선택했습니다.

과거에 inout을 mutating으로 대체하는 논의가 있었던 만큼 Mutable 같은 이름도 후보였습니다.

value 프로퍼티 이름

subscript로 reference[]처럼 역참조하거나, target 같은 이름도 검토했지만, 제안된 Unique 타입의 인터페이스와 일관성을 맞추기 위해 value로 결정했습니다.

Conclusion

Borrow와 Inout은 Swift에서 오래도록 아쉬웠던 "안전한 참조" 문제를 드디어 언어 차원에서 해결하는 제안입니다.

클래스 박싱의 오버헤드도, UnsafePointer의 위험성도 없이, 값에 대한 참조를 first-class로 다룰 수 있게 된다는 점이 정말 기대됩니다.

특히 딕셔너리나 배열의 특정 요소를 반복적으로 수정해야 하는 시나리오에서 성능 이점이 체감될 것 같고, ~Escapable 타입 생태계와 함께 Swift의 소유권 모델이 한층 더 정교해지는 느낌이거든요

References

swift-evolution/proposals/0519-borrow-inout-types.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

SE-0507: Borrow and Mutate Accessors

Hi everyone, The review of SE-0507 "Borrow and Mutate Accessors" begins now and runs through February 9, 2026. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to

forums.swift.org

[SE-0518] tide-Sendable

GREEN.1229 — Sun, 5 Apr 2026 08:26:02 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0518 — ~Sendable로 non-Sendable 타입을 명시적으로 표현하기에 대해 정리해보겠습니다

Intro

Proposal: SE-0518
Status: Implemented (Swift 6.4)
Experimental Feature Flag: TildeSendable

Motivation

public 타입이 Sendable을 명시적으로 conform하지 않을 때, 그 의도를 파악하기가 쉽지 않습니다.

아직 Sendable conformance를 추가하지 않은 건지, 아니면 의도적으로 non-Sendable로 설계한 건지가 불분명하거든요.

이를 판단하려면 타입의 스토리지 구조와 동기화 메커니즘 같은 구현 세부사항을 알아야 하는데, 라이브러리 외부에서는 접근하기 어렵습니다.

또한 클래스 자체는 non-Sendable이지만, 특정 서브클래스는 Sendable이어야 하는 상황도 있습니다.

기존에는 이를 아래처럼 unavailable extension으로 표현했는데요.

class Base {
   // ...
}

@available(*, unavailable)
extension Base: Sendable {
}

문제는 unavailable conformance는 서브클래스에 그대로 상속된다는 점입니다.

그래서 thread-safe 서브클래스를 만들려고 해도,

final class ThreadSafe: Base, @unchecked Sendable {
   // ...
}

다음과 같은 경고가 발생합니다.

warning: conformance of 'ThreadSafe' to protocol 'Sendable' is already unavailable

서브클래스가 Sendable이 될 수도 있고 아닐 수도 있는, 이 세 번째 상태를 언어 차원에서 명확하게 표현할 방법이 없었던 거죠.
라이브러리 작성자 입장에서는 API의 Sendable 판단을 체계적으로 하기도 어렵고, 클라이언트에게 의도를 전달하기도 힘든 상황이었습니다.

Solution

SE-0518은 ~Sendable conformance 문법을 도입해 타입이 명시적으로 non-Sendable임을 나타낼 수 있게 합니다.

// `ExecutionResult`는 감사 결과 non-`Sendable`로 명시.
// non-Sendable associated value를 가진 케이스가 있기 때문입니다.
public enum ExecutionResult: ~Sendable {
case success
// ...
// ...
case failure(NonSendable)
// ...
}

// `Base`는 감사 결과 non-`Sendable`로 명시.
// 서브클래스는 non-`Sendable` mutable state를 추가하거나,
// 상태를 보호하거나 상수로 만들어 `Sendable`로 표시될 수 있습니다.
public class Base: ~Sendable {
  // ...
}

// 이 서브클래스는 감사 결과 `Sendable`로 판단됩니다.
public class ThreadSafeImpl: Base, @unchecked Sendable {
    // `Base`의 `value`를 lock 등을 통해 안전하게 접근합니다.
}

// 이 서브클래스는 mutable non-`Sendable` state를 가지므로 non-`Sendable`입니다.
public class UnsafeImpl: Base {
   var x: NonSendable
}

~Sendable 문법은 타입에만 적용 가능합니다. 제네릭 파라미터 같은 다른 선언은 기본적으로 이미 ~Sendable이기 때문입니다.

Detailed Design

~Sendable은 ~Copyable, ~Escapable, ~BitwiseCopyable과 같이 tilde(~) 접두사를 사용해 conformance 억제를 표현합니다.

기본 사용

// Sendable inference 억제
struct NotSendableType: ~Sendable {
    let data: String
}

// 다른 conformance와 함께 사용 가능
struct MyType: Equatable, ~Sendable {
    let id: UUID
}

// 클래스에도 적용 가능
class MyClass: ~Sendable {
    private let data = 0
}

Extension에서는 사용 불가

억제 선언은 반드시 타입 선언부에서 해야 합니다.

Extension에서 사용하면 기존 코드의 의미가 바뀔 위험이 있거든요.

extension Test: ~Sendable {} // Error!

제네릭 파라미터, 프로토콜에는 사용 불가

억제할 implied Sendable 요구사항이 없기 때문에 거부됩니다.

protocol P: ~Sendable {} // Error!
struct Test<T: ~Sendable> {} // Error!
func test<T: ~Sendable>(_: T) {} // Error!

Sendable 요구사항을 만족시킬 수 없음

unavailable extension과 마찬가지로, ~Sendable 타입은 Sendable 요구사항을 만족시킬 수 없습니다.

func processData<T: Sendable>(_ data: T) { }

struct NotSendable: ~Sendable {
    let value: Int
}

processData(NotSendable(value: 42)) // error: type 'NotSendable' does not conform to the 'Sendable' protocol

서브클래스에는 영향 없음

unavailable extension과의 가장 큰 차이점입니다.

~Sendable은 서브클래스에 상속되지 않습니다.

class A: ~Sendable {
}

final class B: A, @unchecked Sendable {
}

func takesSendable<T: Sendable>(_: T) {
}

takesSendable(B()) // Ok!

Sendable과 ~Sendable 동시 사용 불가

무조건적으로 둘 다 conform하려 하면 컴파일 오류가 발생합니다.

// actor는 항상 `Sendable`입니다.
actor A: ~Sendable { // error: cannot both conform to and suppress conformance to 'Sendable'
}

struct Container<T>: ~Sendable {
    let value: T
}

extension Container: Sendable {} // error: cannot both conform to and suppress conformance to 'Sendable'

상위 클래스나 프로토콜에서 상속된 명시적/파생 Sendable conformance에도 동일하게 적용됩니다.

protocol IsolatedProtocol: Sendable {
}

struct Test: IsolatedProtocol, ~Sendable { // error: cannot both conform to and suppress conformance to 'Sendable'
}

@MainActor
class IsolatedBase { // global actor isolated 타입은 `Sendable`입니다.
}

class Refined: IsolatedBase, ~Sendable { // error: cannot both conform to and suppress conformance to 'Sendable'
}

조건부 conformance는 허용

extension Container: Sendable where T: Sendable {} // Ok!

조건부 Sendable conformance는 여전히 유용하거든요.
API 작성자가 타입이 특정 조건에서만 Sendable임을 표현하고 싶을 때 활용할 수 있습니다.

ExplicitSendable 추적 플래그

Swift 컴파일러는 public 타입의 sendability를 감사할 수 있는 방법을 제공합니다.
기존에는 -require-explicit-sendable 플래그를 사용했는데, 이번 제안에서 ~Sendable을 지원하도록 업데이트되고 ExplicitSendable 진단 그룹으로 전환되었습니다.
기본적으로 비활성화되어 있으며, -Wwarning ExplicitSendable로 활성화할 수 있습니다.

Alternatives Considered

@nonSendable 속성

@nonSendable
struct MyType {
    let value: Int
}

이 방법도 고려됐지만, 프로토콜 conformance 방식이 더 ergonomic하고,
~Copyable, ~Escapable 같은 기존 conformance 억제 컨벤션과도 일관성이 있기 때문에 채택되지 않았습니다.

Future Directions

이번 제안은 Sendable에만 집중했지만, Equatable, Hashable, RawRepresentable 같이 암묵적으로 추론되는 다른 프로토콜 conformance에도 ~ 문법이 적용될 수 있습니다.
각각 고유한 특이점이 있어 별도 제안이 필요할 것으로 보입니다.

Conclusion

~Sendable은 작지만 굉장히 실용적인 추가입니다.

기존에는 non-Sendable 의도를 표현하려면 unavailable extension이라는 다소 우회적인 방법을 써야 했고,
서브클래스에 상속된다는 부작용까지 감수해야 했거든요.

이제 ~Sendable로 그 의도를 명확하게 선언하면서, 서브클래스의 Sendable 가능성도 열어둘 수 있게 되었습니다.
라이브러리 작성자 입장에서는 API의 Sendability 추적 및 판단을 훨씬 체계적으로 할 수 있을 것 같습니다

References

swift-evolution/proposals/0518-tilde-sendable.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

Swift 6.3

GREEN.1229 — Sun, 29 Mar 2026 08:58:54 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 Swift 6.3에서 릴리즈된 내용들을 정리해보겠습니다

Intro

2026년 3월 24일, Swift 6.3이 공식 릴리즈되었습니다.

Swift는 소프트웨어 스택의 모든 레이어에서 사용할 수 있는 언어를 목표로 설계되었습니다.

임베디드 펌웨어, 인터넷 규모의 서비스, 풀-피처 모바일 앱을 만들든 간에,

Swift는 강력한 안전성 보장, 필요할 때의 성능 제어, 그리고 표현력 있는 언어 기능과 API를 제공하거든요

Swift 6.3은 이러한 이점들을 스택 전반에 걸쳐 더 넓게 활용할 수 있도록 해줍니다.

이번 릴리즈의 주요 내용은 다음과 같습니다

더 유연한 C 상호운용성
크로스 플랫폼 빌드 툴링 개선
임베디드 환경에서의 Swift 개선
공식 Swift SDK for Android

언어 및 표준 라이브러리

C 상호운용성 (C Interoperability)

Swift 6.3에서는 @c 속성이 도입되었습니다.
이를 통해 Swift 함수와 enum을 C 코드에 노출할 수 있게 됩니다.

함수나 enum에 @c를 붙이면, Swift가 생성된 C 헤더에 해당 선언을 포함시켜주고,
그 헤더를 C/C++ 파일에서 include해서 사용할 수 있게 되거든요

@c
func callFromC() { ... }

// Generated C header

void callFromC(void);

생성되는 C 선언에 커스텀 이름을 지정하는 것도 가능합니다.

@c(MyLibrary_callFromC)
func callFromC() { ... }

// Generated C header

void MyLibrary_callFromC(void);

@c는 @implementation과 함께도 사용할 수 있어요.
이를 통해 C 헤더에 선언된 함수에 대한 Swift 구현을 제공할 수 있습니다.

// C header

void callFromC(void);

// Implementation written in Swift

@c @implementation
func callFromC() { ... }

@c와 @implementation을 함께 사용하면, Swift는 생성된 헤더에 C 선언을 포함시키는 대신, Swift 함수가 C 헤더에 이미 존재하는 선언과 일치하는지 검증합니다.

Module name selectors

Swift 6.3에서는 module selectors가 도입되어, 코드에서 사용하는 API가 어떤 모듈에서 온 것인지 명시적으로 지정할 수 있게 되었습니다.

동일한 이름의 API를 제공하는 모듈을 두 개 이상 import했을 때, module selector를 통해 어떤 API를 사용할지 명확하게 구분할 수 있습니다.

import ModuleA
import ModuleB

let x = ModuleA::getValue() // Call 'getValue' from ModuleA
let y = ModuleB::getValue() // Call 'getValue' from ModuleB

또한 Swift 6.3부터는 Swift 모듈명을 사용해서 concurrency와 String processing 라이브러리 API에 접근하는 것도 가능합니다.

let task = Swift::Task {
  // async work
}

라이브러리 API를 위한 성능 제어

Swift 6.3에서는 라이브러리 작성자가 클라이언트에 대한 컴파일러 최적화를 더 세밀하게 제어할 수 있는 새로운 속성들이 추가되었습니다.

함수 특수화 (Function specialization): @specialize를 사용해 일반적인 구체 타입에 대한 사전 특수화된 generic API 구현을 제공할 수 있습니다.
인라이닝 (Inlining): @inline(always)를 통해 함수에 대한 직접 호출의 인라이닝을 보장합니다. 인라이닝이란 함수 호출부에 함수 본문을 펼치는 컴파일러 최적화인데요, 인라이닝의 이점이 코드 크기 증가보다 크다고 판단될 때만 사용하는 걸 권장합니다.
함수 구현 가시성 (Function implementation visibility): @export(implementation)을 사용해 ABI 안정 라이브러리의 함수 구현을 클라이언트에 노출시킬 수 있습니다. 이를 통해 함수가 더 많은 컴파일러 최적화에 참여할 수 있습니다.

패키지 및 빌드 개선사항

Swift 6.3에서는 Swift Package Manager에 Swift Build의 프리뷰가 통합되었습니다.

이 프리뷰는 지원되는 모든 플랫폼에서 통합 빌드 엔진을 제공해, 크로스 플랫폼 개발 경험을 더 일관되게 만들어줍니다.

그 외 Swift Package Manager 개선사항들은 다음과 같습니다.

공유 매크로 라이브러리를 위한 사전 빌드된 Swift Syntax: 매크로에서만 사용하는 라이브러리에서 swift-syntax 사전 빌드 바이너리를 지원하면서, 공유 매크로 구현 코드를 라이브러리로 분리할 수 있습니다.
유연한 상속 문서 (Flexible inherited documentation): 심볼 그래프를 생성하는 커맨드 플러그인에 상속된 문서를 포함할지 여부를 제어할 수 있습니다.
패키지 트레이트 탐색 (Discoverable package traits): 새로운 swift package show-traits 명령어로 패키지가 지원하는 트레이트를 탐색할 수 있습니다.

코어 라이브러리 업데이트

Swift Testing

Swift Testing에 경고 이슈, 테스트 취소, 이미지 첨부 등 여러 개선사항이 추가되었습니다.

경고 이슈 (Warning issues): Issue.record의 새로운 severity 파라미터를 사용해 테스트 이슈의 심각도를 지정할 수 있습니다.
Issue.record("Something suspicious happened", severity: .warning)처럼 이슈를 경고로 기록할 수 있고, 이는 테스트 결과에 반영되지만 테스트를 실패로 표시하지는 않습니다.
테스트 취소 (Test cancellation): try Test.cancel()을 사용해 시작된 테스트(및 그 태스크 계층)를 취소할 수 있습니다. 파라미터화된 테스트의 개별 인수를 건너뛰거나, 테스트 중 계속 진행하면 안 된다는 조건을 감지했을 때 유용합니다.
이미지 첨부 (Image attachments): Apple 및 Windows 플랫폼에서 테스트 중에 일반적인 이미지 타입을 첨부할 수 있습니다. UIKit 등의 UI 프레임워크와의 새로운 크로스-import 오버레이 모듈을 통해 제공됩니다.

DocC

Swift 6.3에서는 DocC에 세 가지 실험적 기능이 추가되었습니다.

Markdown 출력: 표준 렌더링 JSON과 함께 문서 페이지의 Markdown 버전을 생성할 수 있습니다. docc convert에 --enable-experimental-markdown-output 플래그를 전달하면 사용해볼 수 있습니다.
페이지별 정적 HTML 콘텐츠: 각 페이지의 경량 HTML 요약(제목, 설명, 가용성, 선언, 토론 포함)을 <noscript> 태그 안에 index.html 파일에 직접 내장할 수 있습니다. JavaScript 없이도 검색 엔진 탐색과 스크린 리더 접근성이 향상됩니다. docc convert에 --transform-for-static-hosting --experimental-transform-for-static-hosting-with-content를 전달하면 사용해볼 수 있습니다.
코드 블록 어노테이션: 코드 블록에 새로운 포맷팅 어노테이션이 추가됩니다. 여는 펜스 라인에서 언어 이름 뒤에 콤마로 구분된 목록으로 옵션을 지정합니다:
- nocopy: 클립보드 복사 비활성화
- highlight: 특정 라인 번호 강조
- showLineNumbers: 라인 번호 표시
- wrap: 컬럼 너비에 따라 긴 줄 줄바꿈
```
```swift, nocopy
let config = loadDefaultConfig()
```
```
```
 ```swift, highlight=[1, 3]
let name = "World"       // highlighted
let greeting = "Hello"
print("\(greeting), \(name)!")  // highlighted
```
```
```
```swift, showLineNumbers, wrap=80
func example() { /* ... */ }
```
```

DocC는 라인 인덱스의 유효성을 검사하고 인식되지 않는 옵션에 대해 경고를 표시합니다.
--enable-experimental-code-block-annotations로 사용해볼 수 있습니다.

플랫폼 및 환경

Embedded Swift

Swift 6.3에서 Embedded Swift는 굉장히 다양한 개선사항을 받았습니다.
향상된 C 상호운용성, 더 나은 디버깅 지원, 완전한 링크 모델을 향한 의미있는 진전까지 포함됩니다.

자세한 내용은 Embedded Swift Improvements coming in Swift 6.3 포스팅에서 확인하실 수 있습니다.

Android

Swift 6.3에는 Swift SDK for Android의 첫 번째 공식 릴리즈가 포함되었습니다

이 SDK를 통해 할 수 있는 것들은 다음과 같습니다.

Swift로 네이티브 Android 프로그램 개발 시작
Swift 패키지가 Android 빌드를 지원하도록 업데이트
Swift Java 및 Swift Java JNI Core를 사용해 Kotlin/Java로 작성된 기존 Android 앱에 Swift 코드 통합

이번 릴리즈는 Swift의 크로스 플랫폼 개발 가능성을 크게 열어주는 중요한 이정표라고 볼 수 있습니다!

시작하려면 Getting Started with the Swift SDK for Android 문서를 참고해보세요.

Conclusion

Swift 6.3은 언어 자체의 표현력을 높이는 동시에, 플랫폼 확장성이라는 측면에서도 굉장히 의미있는 릴리즈입니다.

@c 속성을 통한 C 상호운용성 강화, module name selectors를 통한 명확한 API 구분, Swift Testing의 실용적인 개선, 그리고 DocC 실험 기능들까지 — 개발 경험 전반에서 체감할 수 있는 변화들이 많이 담겨있거든요.

무엇보다 Swift SDK for Android의 공식 릴리즈는 Swift가 단순히 Apple 생태계를 넘어 더 넓은 영역으로 뻗어나가고 있다는 신호로 보입니다

Swift 6.3은 지금 바로 사용해볼 수 있습니다. Install Swift 페이지에서 Swift 6.3 툴체인 설치 방법을 확인해보세요!

References

Swift 6.3 Released

Swift is designed to be the language you reach for at every layer of the software stack. Whether you’re building embedded firmware, internet-scale services, or full-featured mobile apps, Swift delivers strong safety guarantees, performance control when y

www.swift.org

Swift 6.2.4

GREEN.1229 — Sun, 22 Mar 2026 07:06:59 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 Swift 6.2.4에서 릴리즈된 내용들을 정리해보겠습니다

Intro

2026년 2월 27일, Swift 6.2.4가 공식 릴리즈되었습니다.

이번 릴리즈는 주로 버그 수정과 성능 개선에 초점을 맞춘 마이너 업데이트입니다.

Xcode 26.3에 Swift 6.2.4가 포함되어 있으며, Swiftly나 Docker를 통해서도 설치할 수 있습니다

설치 방법

Swiftly 사용

swiftly install 6.2.4
# 또는
swiftly install latest

직접 다운로드

Swift.org에서 툴체인을 직접 다운로드할 수 있습니다.

Docker

Docker 이미지는 곧 hub.docker.com/_/swift에서 사용 가능합니다.

Xcode

Xcode 26.3에 Swift 6.2.4가 포함되어 있습니다.

주요 변경사항

Swift 컴파일러

1. for-in 루프의 break/continue 크래시 수정

PR: #86114

variadic generic 타입을 순회하는 for-in 루프에서 continue나 break 문을 사용할 때 런타임 크래시가 발생할 수 있는 문제를 수정했습니다.

컴파일러가 잘못된 jump destination을 선택하는 버그였습니다.

// 이제 정상적으로 동작합니다
for element in packExpansion {
    if someCondition {
        continue // 또는 break
    }
}

2. nonisolated(nonsending) isolation 전달 개선

PR: #86112

nonisolated(nonsending) isolation이 이제 parent isolation을 가정하지 않는 closure로 전달됩니다.

특히 @Sendable 파라미터로 전달되는 closure에서 불필요한 isolation switch를 피할 수 있습니다.

@MainActor func test(_: nonisolated(nonsending) @Sendable () async -> Void) async {}

await test {
    // The closure doesn't leave `@MainActor`.
}

이전에는 이런 closure가 @MainActor를 벗어났다가 다시 들어오는 불필요한 isolation switch가 발생했지만, 이제는 @MainActor를 유지합니다.

Swift Package Manager

1. 대량 소스 파일 선언 시 성능 개선

많은 수의 소스 파일을 명시적으로 선언하는 target을 빌드하거나 의존할 때 성능이 크게 개선되었습니다.

배경: swift-protobuf 1.33.1에서 모든 소스 파일을 명시적으로 선언하도록 변경했는데, 이로 인해 빌드 성능이 크게 저하되는 문제가 있었습니다.

SwiftPM이 각 파일에 대해 다른 모든 파일의 subpath인지 확인하는 O(n²) 연산을 수행했기 때문입니다.

이번 릴리즈에서 이 부분이 최적화되었습니다.

2. 의존성 체인의 default traits 처리 개선

의존성 체인 전반에서 default traits가 올바르게 활성화되도록 처리가 개선되었습니다.

swift-corelibs-foundation

NSString의 buffer overflow 수정

PR: #5287

NSString의 getBytes 메서드에서 buffer overflow가 발생할 수 있는 심각한 버그를 수정했습니다.

문제: _NSCFString.getBytes가 제공된 max buffer length를 읽거나 존중하지 않아서, 충분하지 않은 크기의 buffer가 제공되면 buffer overflow가 발생했습니다.

특히 plutil에서 긴 유니코드 문자열이 포함된 plist를 읽을 때 증상이 나타났습니다.

UTF16 count는 stack buffer를 사용할 만큼 작았지만, UTF8 count는 충분히 커서 stack buffer를 overflow시켰습니다.

해결: 이제 byte iteration 중 max buffer length에 도달하면 중단하도록 개선된 bounds checking이 추가되었습니다.

swift-format

nonisolated(nonsending) 포맷팅 수정

PR: #1124

nonisolated(nonsending) type modifier가 이제 올바르게 포맷팅됩니다.

// 이제 제대로 포맷팅됩니다
func example(_: nonisolated(nonsending) @Sendable () async -> Void) async {
    // ...
}

위험도 평가

모든 변경사항은 Low Risk로 평가되었습니다.

for-in 크래시 수정: variadic generic을 순회하는 루프 내부의 break/continue에만 영향
nonisolated(nonsending) 전달: @Sendable 파라미터이면서 nonisolated(nonsending)인 isolation boundary closure에만 영향
SPM 성능: 명시적으로 선언된 소스 파일이 많은 경우에만 해당
NSString 수정: buffer overflow 취약점 수정으로 안정성 향상

Conclusion

Swift 6.2.4는 크리티컬한 버그 수정과 성능 개선을 포함한 안정화 릴리즈입니다.

특히 NSString의 buffer overflow 수정은 보안 측면에서 중요한 개선이고, SPM의 성능 개선은 대규모 프로젝트에서 체감할 수 있을 것 같습니다.

nonisolated(nonsending)의 isolation 전달 개선도 Swift Concurrency를 사용하는 코드의 성능을 향상시켜줄 것으로 기대됩니다.

Xcode 26.3을 사용하고 계시다면 이미 Swift 6.2.4를 사용하고 계신 거니, 별도로 업데이트할 필요는 없습니다

References

Announcing Swift 6.2.4

We are happy to announce the release of Swift 6.2.4. Install Swift Toolchain Install via Swiftly swiftly install 6.2.4 or swiftly install latest Download toolchain directly from Install Swift | Swift.org Docker images will be available on hub.docker.com/_/

forums.swift.org

Swift.org

Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.

www.swift.org

swift - Official Image | Docker Hub

Docker Official Images are a curated set of Docker open source and drop-in solution repositories. Why Official Images? These images have clear documentation, promote best practices, and are designed for the most common use cases.

hub.docker.com:443

[SE-0515] Allow reduce to produce noncopyable results

GREEN.1229 — Sat, 14 Mar 2026 07:40:20 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0515 Allow reduce to produce noncopyable results에 대해 정리해보겠습니다

Intro

Swift의 reduce는 정말 유용한 함수이지만, 몇 가지 한계가 있었습니다.

noncopyable 타입을 다룰 수 없었고, initial value를 borrow하는 방식이라 불필요한 복사가 발생했어요.

SE-0515는 reduce를 개선합니다

Noncopyable initial value와 result를 허용하고
Copyable일 때도 initial value를 consume하도록 변경합니다

이미 PR이 Accepted 상태이고 구현도 완료되었으니, 곧 현업에서도 쓸 수 있을 것 같습니다

왜 필요한가?

Noncopyable 타입은 SE-0390에서 도입되어 타입의 의미론과 성능을 제어하는 강력한 메커니즘을 제공합니다.

Sequence는 (아직은) noncopyable 타입을 담을 수 없지만, reduce의 accumulation argument는 sequence와 독립적입니다.

따라서 initial value를 borrow 대신 consume하면, 복사 능력에 의존하지 않고도 reduce를 구현할 수 있습니다.

현재 reduce의 문제점

현재 reduce 구현은 parameter를 borrow합니다.

func reduce<Result>(
  _ initialResult: Result,
  _ nextPartialResult:
    (_ partialResult: Result, Element) throws -> Result
) rethrows -> Result {
  var accumulator = initialResult
  for element in self {
    accumulator = try nextPartialResult(accumulator, element)
  }
  return accumulator
}

여기서 borrow는 암묵적입니다.

initializer가 아닌 argument의 기본값이니까요.

그래서 문제가..?

첫 단계가 항상 initialResult의 mutable copy를 만드는 겁니다.

var accumulator = initialResult  // 복사 발생!

이 패턴은 initial의 올바른 calling convention이 consuming이어야 한다는 걸 강하게 암시합니다.

만약 값이 copyable이면,

호출자가 복사를 만듭니다
단, optimizer가 마지막 사용임을 확인하면 복사를 완전히 제거할 수 있습니다

이런 경우는 reduce에서 매우 흔합니다. "initial value"가 종종 reduction만을 위해 생성되니까요.

솔루션

reduce를 noncopyable 값에서도 동작하도록 일반화하면, initial value를 consume하는 게 필수가 됩니다.

var accumulator = initialResult가 더 이상 컴파일되지 않으니까요.

즉, 새 버전의 reduce는 이렇게 작성됩니다.

extension Sequence {
  public func reduce<Result: ~Copyable>(
    _ initialResult: consuming Result,
    _ nextPartialResult:
      (_ partialResult: consuming Result, Element) throws -> Result
  ) rethrows -> Result

  public func reduce<Result: ~Copyable>(
    into initialResult: consuming Result,
    _ updateAccumulatingResult:
      (_ partialResult: inout Result, Element) throws -> ()
  ) rethrows -> Result
}

실제 구현

public func reduce<Result: ~Copyable>(
  _ initialResult: consuming Result,
  _ nextPartialResult:
    (_ partialResult: consuming Result, Element) throws -> Result
) rethrows -> Result {
  for element in self {
    initialResult = try nextPartialResult(initialResult, element)
  }
  return initialResult
}

더 이상 initialResult 값을 복사할 필요가 없습니다. consuming(즉, owned not borrowed)으로 받으니까요!

reduce(::)와 reduce(into:_:)의 차이

이 시점에서 두 함수는 거의 동일해지고, reduce(into:_:)의 동기가 줄어듭니다.

어떤 걸 쓸지는 주로 개발자 선택의 문제가 됩니다.

성능 개선

"세계에서 가장 느린 map" 문제

이 변경은 고전적인 세 가지 원인 중 하나를 제거합니다.

array.reduce([]) { $0 + [$1] }

이건 여전히 O(n²)입니다.

+가 argument를 borrow하고 모든 element를 복사한 새 array를 반환
[$1]이 버릴 거면서도 새 array buffer를 할당

하지만 새 reduce로는 이렇게 쓸 수 있습니다.

array.reduce([]) { $0.append($1); return $0 }

이제 다음과 같은 성능을 얻습니다.

array.reduce(into: []) { $0.append($1) }

약간은 더 reduce(into:_:)와 동일한 성능이죠!

주의사항

물론 이런 모든 비효율성은 optimizer가 heroic optimization을 수행하면 제거될 수 있습니다.

하지만 이런 heroic optimization은 조금만 복잡한 예시에서는 무너지는 경향이 있어서, 성능 절벽으로 이어집니다.

reduce(into:_:)는?

reduce(into:_:)는 이미 argument를 consuming으로 받습니다.

따라서 유일한 변경은 Result: ~Copyable 추가뿐입니다.

향후 방향

~Escapable 지원

reduce는 ~Escapable 값에서도 동작하도록 업데이트될 수 있습니다.

이를 위해서는 함수와 closure parameter 모두에 lifetime annotation이 필요한데, 후자는 Swift에서 아직 지원되지 않습니다.

Conclusion

SE-0515는 이미 Accepted되었고 구현도 완료된 상태입니다.

개인적으로는 정말 합리적인 개선이라고 생각합니다.

reduce가 initial value를 borrow하는 건 원래부터 이상했어요.

첫 줄에서 바로 복사하는데 말이죠.

이제 noncopyable 타입도 지원하고, copyable 타입에서도 불필요한 복사를 줄일 수 있게 되었습니다.

"세계에서 가장 느린 map" 같은 실수도 조금 덜 치명적으로 만들어주는 좋은 변경이네요

References

swift-evolution/proposals/0515-noncopyable-reduce.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

[Pitch] Allow `reduce` to produce noncopyable results

Hi Swift Evolution, It is obligatory that I doom this pitch as possibly the least controversial pitch I can think of. Allow reduce to produce noncopyable results Proposal: SE-NNNN Authors: Ben Cohen Review Manager: TBD Status: Awaiting implementation or Aw

forums.swift.org

SE-0515: Allow `reduce` to produce noncopyable results

Hi everybody. The review of SE-0515: Allow reduce to produce noncopyable results begins now and runs through March 10, 2026. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you

forums.swift.org

[Accepted] SE-0515: Allow `reduce` to produce noncopyable results

The review of SE-0515: Allow reduce to produce noncopyable results has ended, and the Language Steering Group has decided to accept the proposal. There was unanimous support for what the community sees as an obvious generalization of the existing reduce AP

forums.swift.org

[SE-0514] Hashable Conformance for Dictionary.Keys, CollectionOfOne and EmptyCollection

GREEN.1229 — Mon, 2 Mar 2026 09:14:46 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0514 Hashable Conformance for Dictionary.Keys, CollectionOfOne and EmptyCollection에 대해 정리해보겠습니다

Intro

Swift 표준 라이브러리의 몇몇 collection 타입들이 Hashable을 conform하지 않는 게 있습니다.

Dictionary.Keys, CollectionOfOne, EmptyCollection이 바로 그것들인데요.

이번 SE-0514는 이 세 타입에 Hashable conformance를 추가하는 제안입니다.

특히 Dictionary.Keys는 모든 key가 이미 Hashable인데 keys view 자체는 Hashable이 아닌 게 좀 이상하죠.

간단하지만 일관성을 높여주는 개선입니다

현재 2026년 3월 6일까지 리뷰가 진행 중입니다!

왜 필요한가?

Dictionary.Keys

Dictionary.Keys는 단순히 dictionary의 keys에 대한 view입니다.

Dictionary의 모든 key는 Hashable을 conform하죠.

따라서 Dictionary.Keys 자체도 자동으로 그리고 무조건적으로 Hashable을 conform해야 합니다.

CollectionOfOne과 EmptyCollection

CollectionOfOne과 EmptyCollection은 상대적으로 덜 사용되는 타입들입니다.

이들에 Hashable conformance를 추가하는 건 완전성과 다른 표준 라이브러리 collection 타입들과의 일관성을 위해서입니다.

참고로 CollectionOfOne은 Equatable도 conform하지 않아서, 이 제안에서는 그것도 함께 추가합니다.

솔루션

표준 라이브러리에 다음을 추가합니다.

Dictionary.Keys와 EmptyCollection: 무조건적 Hashable conformance
CollectionOfOne: 조건부 Equatable과 Hashable conformance

상세 설계

Dictionary.Keys

Dictionary.Keys는 무조건적인 Hashable conformance를 얻습니다.

Dictionary의 key는 항상 Hashable이니까요.

Hash 구현은 commutative hashing algorithm(개별 element hash의 XOR)을 사용해서, 두 Dictionary.Keys collection이 같은 element를 포함하면 iteration order와 관계없이 같은 hash value를 갖도록 합니다.

extension Dictionary.Keys {
  @_alwaysEmitIntoClient
  public func hash(into hasher: inout Hasher) {
    var commutativeHash = 0
    for element in self {
      // Note that, similar to `Set`'s and `Dictionary`'s hashing algorithms, we use a copy of our own hasher here.
      // This makes hash values dependent on its state, eliminating static collision patterns.
      var elementHasher = hasher
      elementHasher.combine(element)
      commutativeHash ^= elementHasher._finalize()
    }
    hasher.combine(commutativeHash)
  }

  @_alwaysEmitIntoClient
  public var hashValue: Int { // Prevent compiler from synthesizing hashValue.
    var hasher = Hasher()
    self.hash(into: &hasher)
    return hasher.finalize()
  }
}

@available(SwiftStdlib 6.4, *)
extension Dictionary.Keys: Hashable {}

사용 예시

let batch1 = ["apple": 1, "banana": 2, "cherry": 3, "date": 4]
let batch2 = ["date": 10, "banana": 20, "apple": 30, "cherry": 40]
let batch3 = ["mango": 5, "orange": 6, "papaya": 7]

let uniqueBatches = Set([batch1.keys, batch2.keys, batch3.keys])

print(uniqueBatches)
// [Dictionary.Keys(["orange", "mango", "papaya"]), Dictionary.Keys(["banana", "apple", "date", "cherry"])]

batch1.keys와 batch2.keys는 같은 key들을 포함하므로 Set에서 하나로 처리됩니다!

CollectionOfOne

CollectionOfOne은 조건부 conformance를 얻습니다.

Element가 Equatable이면 Equatable
Element가 Hashable이면 Hashable

Hash value는 포함하고 있는 단일 element에서 파생됩니다.

extension CollectionOfOne where Element: Equatable {
  @_alwaysEmitIntoClient
  public static func ==(lhs: CollectionOfOne<Element>, rhs: CollectionOfOne<Element>) -> Bool {
    return lhs._element == rhs._element
  }
}

extension CollectionOfOne where Element: Hashable {
  @_alwaysEmitIntoClient
  public func hash(into hasher: inout Hasher) {
    hasher.combine(self._element)
  }

  @_alwaysEmitIntoClient
  public var hashValue: Int { // Prevent compiler from synthesizing hashValue.
    var hasher = Hasher()
    self.hash(into: &hasher)
    return hasher.finalize()
  }
}

@available(SwiftStdlib 6.4, *)
extension CollectionOfOne: Equatable where Element: Equatable {}

@available(SwiftStdlib 6.4, *)
extension CollectionOfOne: Hashable where Element: Hashable {}

EmptyCollection

EmptyCollection은 무조건적인 Hashable conformance를 얻습니다.

모든 empty collection은 element 타입과 관계없이 동일하므로, 모두 같은 hash value를 가집니다.

Hash 함수는 단순히 값 0을 combine하는데, 이는 empty set, dictionary, array의 hashing convention과 일치합니다.

extension EmptyCollection {
  @_alwaysEmitIntoClient
  public func hash(into hasher: inout Hasher) {
    hasher.combine(0)
  }

  @_alwaysEmitIntoClient
  public var hashValue: Int { // Prevent compiler from synthesizing hashValue.
    var hasher = Hasher()
    self.hash(into: &hasher)
    return hasher.finalize()
  }
}

@available(SwiftStdlib 6.4, *)
extension EmptyCollection: Hashable {}

호환성

Source compatibility

순수하게 additive한 변경입니다.

다만 이미 자체적으로 redundant conformance를 제공한 코드는 경고가 발생할 수 있습니다.

ABI compatibility

표준 라이브러리 ABI의 순수한 확장이고, 기존 기능은 변경하지 않습니다.

Adoption 영향

새로운 conformance는 Swift 6.4 이상이 필요합니다.

이전 Swift 버전을 지원해야 한다면 이렇게 하면 됩니다.

#if swift(<6.4)
  extension Dictionary.Keys: @retroactive Hashable {}
#endif

FYI. 이전 Swift 버전에서 이미 이런 함수를 구현했다면, 런타임에 binary compatibility 이슈가 발생할 낮은 이론적 위험이 있습니다.

특히 구현이 표준 라이브러리 구현과 근본적으로 호환되지 않거나 충돌하는 경우입니다.

고려된 대안

EmptyCollection의 Hashable conformance를 포함하지 않기?

완전성과 다른 표준 라이브러리 collection 타입들과의 일관성 외에도, hash-based context에서 EmptyCollection을 사용하는 케이스는 피할 수 있습니다.

예를 들어 result ?? EmptyCollection<T> 대신 다른 방법을 쓸 수도 있죠.

하지만 그런 workaround가 해당 use case에 idiomatic하지 않을 수 있습니다.

그래서 일관성을 위해 포함시키기로 했습니다.

Conclusion

현재 SE-0514는 2026년 3월 6일까지 리뷰가 진행 중입니다.

개인적으로는 정말 당연하게 있어야 할 conformance들이라고 생각합니다.

특히 Dictionary.Keys는 모든 key가 이미 Hashable인데 keys view가 Hashable이 아닌 게 이상했거든요.

CollectionOfOne과 EmptyCollection은 덜 사용되지만, 표준 라이브러리의 일관성을 높여주는 좋은 제안이라 생각됩니다

References

swift-evolution/proposals/0514-hashable-conformance-for-dictionarykeys-collectionofone-emptycollection.md at main · swiftlang/s

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

[Pitch] Hashable Conformance for Dictionary.Keys, CollectionOfOne and EmptyCollection

Introduction This proposal adds Hashable conformance to three standard library collection types: Dictionary.Keys, CollectionOfOne and EmptyCollection. Motivation Dictionary.Keys Dictionary.Keys is simply a view of the dictionary's keys, and every key in a

forums.swift.org

SE-0514: Hashable Conformance for Dictionary.Keys, CollectionOfOne and EmptyCollection

Hello, Swift community! The review of SE-0514: Hashable Conformance for Dictionary.Keys, CollectionOfOne and EmptyCollection begins now and runs through March 6, 2026. Reviews are an important part of the Swift evolution process. All review feedback should

forums.swift.org

[SE-0510] Introduce Dictionary.mapValuesWithKeys

GREEN.1229 — Sat, 21 Feb 2026 00:45:23 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0510 Introduce Dictionary.mapValuesWithKeys에 대해 정리해보겠습니다

Intro

Dictionary의 값을 변환할 때 key 정보도 함께 필요한 경우가 종종 있습니다.

하지만 현재는 이런 작업을 하려면 init(uniqueKeysWithValues:)나 reduce(into:)를 써야 하는데, 이들은 불필요하게 dictionary를 rehashing하거나 재할당하는 비용이 발생합니다.

SE-0510은 이 문제를 해결하기 위해 mapValuesWithKeys라는 새로운 메서드를 제안합니다.

Key 정보를 transformation closure에 전달하면서도 성능 오버헤드 없이 값만 변환할 수 있습니다

현재 시점에서는 리뷰가 드래프트 상태이고 진행중이지만 곧 반영되지 않을까 싶습니다.

왜 필요한가?

Dictionary 값을 변환하면서 key도 함께 사용해야 하는 경우, 현재는 이렇게 해야 합니다.

let new: [Key: NewValue] = .init(
    uniqueKeysWithValues: old.lazy.map { ($0, transform(id: $0, payload: $1)) }
)
// or
let new: [Key: NewValue] = old.reduce(into: [:]) {
    $0[$1.key] = transform(id: $1.key, payload: $1.value)
}

두 방법 모두 심각하게 비효율적입니다.

첫 번째 방법: 모든 key를 다시 hashing
두 번째 방법: 여러 번의 중간 재할당 발생

벤치마크를 돌려보면 첫 번째가 중간 재할당이 적어서 그나마 조금 덜 나쁜 정도입니다.

Dictionary key를 변환하는 케이스도 있지만, 이 제안은 key는 절대 수정하지 않고 컨텍스트로만 사용하는 케이스에 집중하고 있습니다.

제안된 솔루션

Dictionary에 새로운 메서드를 추가합니다.

extension Dictionary {
    @inlinable public func mapValuesWithKeys<T, E>(
        _ transform: (Key, Value) throws(E) -> T
    ) throws(E) -> Dictionary<Key, T>
}

사용 예시

let balances: [Currency: Int64] = [.USD: 13, .EUR: 15]
let displayText: [Currency: String] = balances.mapValuesWithKeys {
    "\($0.alpha3) balance: \($1)"
}

간단하죠?
Key 정보를 사용하면서도 rehashing 없이 깔끔하게 값만 변환합니다.

상세 설계

구현은 기존 mapValues와 유사하지만, storage iteration loop 내부에서 key와 value를 함께 transformation closure에 전달합니다.

Apple 플랫폼 호환성

Apple 플랫폼에서 Dictionary는 Cocoa dictionary로 backing될 수 있습니다.

하지만 큰 문제는 없다고 말하고 있습니다.

__CocoaDictionary에도 _NativeDictionary와 본질적으로 동일한 메커니즘을 추가하면 되고, 새로운 mapValuesWithKeys가 기존 mapValues처럼 두 구현 사이에서 dispatch하면 됩니다.

고려된 대안들

기존 mapValues 오버로딩?

원래 초안에서는 기존 mapValues 메서드를 오버로딩해서 Key와 Value를 모두 받는 closure를 지원하려고 했습니다.

하지만 이게 source-breaking인 걸 발견했어요.

드물지만 value 타입이 2-tuple인 dictionary에서 mapValues를 호출하는 경우가 있거든요.

let dict: [String: (Int, String)] = ["a": (1, "x")]
dict.mapValues { ... } // 모호해짐

그래서 source compatibility를 위해 새로운 이름 mapValuesWithKeys를 선택했습니다.

compactMapValues도 추가?

mapValuesWithKeys를 추가하면 compactMapValues와 API 비대칭이 생깁니다.

compactMapValues는 key context를 지원하지 않으니까요.

하지만 compactMapValues는 본질적으로 reduce(into:)의 shorthand라서 성능 측면의 동기가 훨씬 약하거든요.

아무것도 하지 않기?

Dictionary는 extensively frozen type이라서, 개발자가 user space에서 stable-but-unspecified implementation detail에 의존해서 key context를 지원하도록 retrofit할 수도 있습니다.

하지만 이건 좋은 워크플로우가 아니고 권장해서도 안 됩니다.

향후 방향

mapValues 이름 재할당?

미래에는 기존 mapValues 메서드를 mapValuesWithoutKeys 같은 이름으로 바꿀 수도 있습니다.

그러면 mapValues 이름을 key context를 제공하는 버전에 재할당할 수 있겠죠.

다음 언어 모드에서 가능할 것 같습니다.

OrderedDictionary 변경 (swift-collections)

이 제안의 자연스러운 확장으로, swift-collections 패키지의 OrderedDictionary 타입도 mapValuesWithKeys 메서드를 가질 수 있습니다.

extension OrderedDictionary {
    @inlinable public func mapValuesWithKeys<T, E>(
        _ transform: (Key, Value) throws(E) -> T
    ) throws(E) -> OrderedDictionary<Key, T>
}

OrderedDictionary의 성능 향상은 Dictionary보다 더 클 수 있습니다.

OrderedDictionary는 keys와 values를 위한 표준 Array와 lookup을 위한 sidecar hash table을 유지하거든요.

현재 workaround(reduce나 init)는 전체 hash table을 재구성하고 keys array를 eager copy해야 합니다.

대신 zipped iteration을 사용해서 underlying _keys와 _values array를 새로운 values array로 매핑하고, _keys table(hash table __storage 포함)을 복사하면 됩니다.

이건 mutate하지 않으면 O(1) copy-on-write이고, 나중에 mutate하면 O(n)입니다.

Conclusion

Dictionary 값을 변환하면서 key도 사용하는 건 흔한 패턴인데, 지금까지는 불필요한 성능 비용을 감수해야 했는데 이런 메서드가 제공되면 조금 더 편하게 사용될 수 있을것 같네요.

특히 Currency 같은 enum을 key로 쓰면서 display text를 만드는 예시처럼, key가 formatting context를 제공하는 경우가 많잖아요

간단한 추가지만 현업에서 많이 쓰일 것 같네요

References

Giving Dictionary.mapValues(_:) access to the associated key

currently, when it is needed to compute the mapped dictionary value using the dictionary key, it is required to do one of the following: let new: [Key: NewValue] = .init( uniqueKeysWithValues: old.lazy.map { ($0, transform(id: $0, payload: $1)) } ) // or l

forums.swift.org

SE-0510: Dictionary mapValuesWithKeys

The review of SE-0510: Dictionary mapValuesWithKeys begins now and runs through February 17, 2026. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your fe

forums.swift.org

[SE-0508] Array expression trailing closures

GREEN.1229 — Sat, 14 Feb 2026 15:44:20 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0508 Array expression trailing closures에 대해 정리해보겠습니다

Intro

Swift에서 trailing closure는 정말 자주 쓰는 문법이죠.

그런데 array나 dictionary 타입 뒤에는 trailing closure를 쓸 수 없다는 걸 아셨나요?

[String] 같은 타입 뒤에 중괄호를 쓰면 파서가 제대로 인식하지 못해서 에러가 발생합니다.

이번 SE-0508은 바로 이 제약을 풀어주는 제안입니다.

이미 Accepted 상태이고 구현도 완료되었으니, 곧 실제로 활용할 수 있을거에요

왜 필요한가?

Array에 trailing closure를 받는 init을 정의하는 건 꽤 합리적인 디자인입니다.

예를 들어 @ArrayBuilder result builder가 있다면

extension Array {
    init(@ArrayBuilder build: () -> [Element]) {
        self = build()
    }
}

또는 nil을 반환할 때까지 element를 생성하는 init

extension Array {
    init(generate: () -> Element?) {
        self = []
        while let element = generate() {
            append(element)
        }
    }
}

하지만 이렇게 쓸 수 없습니다

대부분의 경우 closure를 받는 init은 trailing closure 문법으로 호출할 수 있습니다.

그런데 Array나 Dictionary 타입에서는 파서가 이를 허용하지 않아요.

// error: 'let' declarations cannot be computed properties
let value = [String] {
  "a"
}

// error: variable with getter/setter cannot have an initial value
var value = [String] {
  "a"
}

// error: closure expression is unused
let value = [String]
{
  "a"
}

대신 이렇게 써야 합니다.

let value = [String].init {
  "a"
}

let value = [String]() {
  "a"
}

InlineArray는 된다?

흥미롭게도 InlineArray에서는 trailing closure가 이미 지원됩니다:

let powersOfTwo = [4 of Int] { index in
  1 << index
}

Array와 Dictionary에서만 안 되는 건 불필요한 제약이고, InlineArray와도 일관성이 없습니다.

제안된 해결책

Array 타입과 dictionary 타입 뒤에 trailing closure를 쓸 수 있게 합니다.

let value = [String] {
  "a"
}

let value = [String: Int] {
  (key: "a", value: 42)
}

이제 이런 코드가 정상적으로 파싱되고 컴파일됩니다!

어떻게 동작하나?

현재 파싱 동작을 이해하려면 두 가지를 알아야 합니다.

1. [...]는 항상 literal로 파싱됨

표현식을 파싱할 때 [...] 토큰은 항상 array나 dictionary literal로 파싱됩니다.

[String]이나 [String: Int] 같은 경우, 필요하면 타입 체크 단계에서 array/dictionary 타입으로 변환됩니다.

[String]이 실제로는 let String = "a" 프로퍼티를 사용하는 단일 요소 array literal일 수도 있으니까요.

2. 중괄호는 trailing closure... 단 literal 뒤는 제외

표현식 뒤에 { 토큰이 오면 trailing closure로 해석됩니다.

단, 이전 표현식이 literal인 경우는 제외입니다.

Swift 5.2에서 callAsFunction이 도입되기 전(SE-0253)까지는 이게 합리적이었습니다.

literal 뒤에 trailing closure가 올 valid한 케이스가 없었거든요.

솔루션

Array와 dictionary literal 뒤에 trailing closure를 허용하도록 변경합니다.

이렇게 하면 이런 init(_:) trailing closure 예시가 제대로 파싱되고 컴파일됩니다.

let value = [String] {
  "a"
}

let value = [String: Int] {
  (key: "a", value: 42)
}

추가 효과: callAsFunction도 지원

결과적으로 callAsFunction trailing closure도 지원됩니다.

extension Array {
    func callAsFunction<T>(mapElement: (Element) -> T) -> [T] {
        map(mapElement)
    }
}

let value = ["a", "b", "c"] {
    $0.uppercased()
}

작은 비용으로 언어의 표현력과 일관성이 크게 향상됩니다.

호환성

Source compatibility

이 파싱 변경은 array literal 뒤에 오는 기존 closure literal의 의미를 바꿉니다.

하지만 현재 실제로 컴파일되는 케이스는 거의 없어요.

대부분은 closure expression is unused 에러가 납니다.

["a", "b", "c"] { // error: closure expression is unused
  "a"
}

["a", "b", "c"]
{ "a" } // error: closure expression is unused

에러가 안 나는 유일한 케이스

Closure를 받는 result builder에서만 에러가 안 납니다.

@resultBuilder
enum FunctionArrayBuilder {
    static func buildBlock(_ components: (() -> Void)...) -> [() -> Void] {
        components
    }
}

@FunctionArrayBuilder
var buildFunctions: [() -> Void] {
    let array = ["a", "b", "c"]
    { print(array) }
}

이 코드는 이제 컴파일되지 않습니다.

하지만 이 result builder 케이스는 이미 매우 취약하고 비실용적입니다.

왜 취약한가?

연속된 closure literal은 세미콜론 없이 지원 안 됨

@FunctionArrayBuilder
var buildFunctions: [() -> Void] {
    { print("a") }
    { print("b") } // error: extra trailing closure passed in call
}

작은 변경으로도 컴파일이 깨짐

// Compiles
@FunctionArrayBuilder
var buildFunctions: [() -> Void] {
    let array = ["a", "b", "c"]
    { print(array) };
    { print(array.count) }
}

// Doesn't compile
@FunctionArrayBuilder
var buildFunctions: [() -> Void] {
    let array = ["a", "b", "c"]
    let count = array.count
    { print(array) }; // error: cannot convert value of type '()' to closure result type 'Bool'
    { print(count) }
}

callAsFunction이 있으면 의미가 바뀜

extension Int {
  func callAsFunction(_ closure: () -> Void) -> Int {
    closure()
    return self
  }
}

@FunctionArrayBuilder
var buildFunctions: [() -> Void] {
    let array = ["a", "b", "c"]
    let count = array.count
    { print(array) }; // callAsFunction trailing closure, not an accumulated result builder value
    { print(count) }
}

이런 케이스는 실제로 사용되는 예시가 없고, 더 복잡한 파싱 규칙으로 수용하는 것보다 이 source break를 받아들이는 게 낫다고 판단했습니다.

ABI compatibility

기존 선언에 대한 새로운 callsite 문법만 추가하는 거라 ABI에 영향이 없습니다.

향후 방향

모든 literal에 trailing closure 허용?

이 제안은 array와 dictionary literal만 지원합니다.

더 나아가서 모든 literal에 trailing closure를 허용할 수도 있어요.

extension String {
  func callAsFunction(_ closure: (String) -> Void) {
    closure(self)
  }
}

"Hello world" { // currently, error: closure expression is unused 
  print($0)
}

다른 trailing closure 케이스와 더 일관되고, 특별한 단점도 없습니다.

다만 array/dictionary만큼 강력하게 동기부여되지는 않아요.

Array와 dictionary는 타입 표현식이 literal로 파싱되는 잠재적 모호성 때문에 특별하거든요.

고려된 대안들

추가 파싱 휴리스틱

같은 줄에서만 허용?

Source break는 array literal 다음 줄에 result builder closure가 오는 경우입니다.

@FunctionArrayBuilder
var buildFunctions: [() -> Void] {
    let array = ["a", "b", "c"]
    { print(array) }
}

같은 줄에 있으면 이미 컴파일되지 않습니다.

@FunctionArrayBuilder
var buildFunctions: [() -> Void] {
    let array1 = ["a", "b", "c"] { // error: cannot convert return expression of type '()' to return type '[String]'
        print(array)
    }

    let array2 = ["a", "b", "c"] { // error: variable with getter/setter cannot have an initial value
        ["d"]
    }
}

같은 줄일 때만 trailing closure로 처리하면 source break를 피할 수 있습니다.

하지만 이건 다른 모든 brace/trailing closure 케이스와 일관성이 없어요.

let array = ["a", "b", "c"].map 
{ 
  $0.uppercased()
}

if array.count >= 3
{
  print("success: \(array)")
}

이런 임의적인 불일치는 코드 포매팅 도구 같은 생태계 전반에 복잡성을 추가합니다.

Array 타입만 지원?

Array/dictionary 타입만 지원하고 다른 literal은 제외하는 방법도 있습니다.

[String] 타입은 valid한 표현식이 아니니까 source compatibility 문제가 없겠죠.

하지만 파싱 시점에는 [String]이 타입인지 literal인지 알 수 없습니다.

let String = "a"
let array = [String] // an array literal, ["a"]
{ print(array) }

단일 요소 array/dictionary literal이고 단일 identifier를 포함하는 경우만 허용할 수도 있지만, 이러면 callAsFunction 케이스가 불필요하게 제거됩니다.

Conclusion

SE-0508은 이미 Accepted되었고 구현도 완료된 상태입니다.

개인적으로는 정말 합리적인 개선이라고 생각해요.

InlineArray에서는 되는데 Array에서는 안 된다는 게 말이 안 됐거든요.

@ArrayBuilder 같은 result builder와 함께 쓰면 정말 깔끔한 API를 만들 수 있을 것 같습니다.

작은 변경이지만 언어의 일관성과 표현력을 크게 높여주는 개선이네요

References

swift-evolution/proposals/0508-array-expression-trailing-closures.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

Support trailing closure syntax for single-argument Array and Dictionary initializers

In the recent discussion about @ArrayBuilder, it came up that trailing closure syntax is not currently supported in the most intuitive way for Array initializers like init(@ArrayBuilder build: () -> [Element]): I investigated this on the parsing side, and

forums.swift.org

SE-0508: Array expression trailing closures

Hi everyone, The review of SE-0508: Array expression trailing closures begins now and runs through February 12, 2026. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would l

forums.swift.org

[Accepted] SE-0508: Array expression trailing closures

Hi all, The review of SE-0508: Array expression trailing closures concluded on February 12, 2026. The language steering group has decided to accept the proposal. Feedback was positive on adding language support for trailing closures after sugared array and

forums.swift.org

[SE-0507] Borrow and Mutate Accessors

GREEN.1229 — Sun, 8 Feb 2026 08:14:50 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0507 Borrow and Mutate Accessors에 대해 정리해보겠습니다

Intro

Swift의 property accessor는 계속 발전중입니다.

기존에는 get, set, 그리고 최근 추가된 yielding borrow, yielding mutate가 있었는데요.

이번 SE-0507은 새로운 borrow와 mutate accessor를 제안합니다.

얘네들은 borrowing semantics를 사용해서 복사 오버헤드 없이 값에 접근할 수 있고, yielding accessor보다 성능이 좋습니다.

특히 non-copyable 타입을 다루는 collection이나 성능이 중요한 저수준 데이터 구조에 유용할 거예요

현재 2026년 2월 9일까지 리뷰가 진행 중이긴한데 현 시점에서 Draft 상태라 계획대로 내일까지 반영될진 지켜봐야 알것 같아요.

왜 필요한가?

기존 accessor들은 각각 한계가 있습니다.

문제 1: get은 복사해야 한다

get accessor는 값을 복사하거나 새로 생성해서 반환해야 합니다.

복사의 코스트가 많이 들거나 불가능한 경우엔 쓸 수 없죠.

struct NC: ~Copyable { ... }
struct ContainerOfNoncopyable {
    private var _element: NC
    var element: Element {
        return _element //   ERROR: Cannot copy `_element`
    }
}

Non-copyable 값을 저장하는 collection은 subscript에 get을 쓸 수 없습니다.

문제 2: yielding accessor는 오버헤드가 크다

yielding mutate와 yielding borrow는 coroutine을 사용합니다.

접근 전후로 코드를 실행할 수 있어서 유연하지만, 그만큼 오버헤드가 있습니다.

Coroutine을 위한 메모리 할당
여러 번의 함수 호출
접근 scope가 제한됨 (함수가 끝나기 전에 완료되어야 함)

struct Element: ~Copyable {
  var span: Span<...> { ... }
}

struct Wrapper: ~Copyable {
    private var _element: Element
    var element: Element {
        yielding borrow { // ❗️Note: Using `yielding borrow` accessor
            yield _element
        }
    }
}

func getSpan(wrapper: borrowing Wrapper) -> Span<...> {
    // Because we're reading `element` from a yielding accessor,
    // its access must finish before `getSpan` returns.
    // But `span` cannot outlive `element`, so ...

    //   ERROR: lifetime-dependent value escapes its scope
    return wrapper.element.span
}

Borrowing accessor는 이 두 문제를 모두 해결합니다.

제안된 솔루션

새로운 borrow와 mutate 키워드로 accessor를 정의합니다.

struct RigidWrapper<Element: ~Copyable>: ~Copyable {
    var _element: Element
    var element: Element {
        borrow {
            return _element
        }
        mutate {
            return &_element
        }
    }
}

borrow: 읽기 전용 접근, 복사하지 않음
mutate: 읽기/쓰기 접근, &로 mutable reference 반환

yield 대신 return을 쓰는 게 차이점입니다.

물론 single expression이면 return 키워드는 생략 가능합니다.

상세 설계

반환 값의 제약

Borrowing accessor는 저장된 값만 반환할 수 있습니다.

local이나 temporary 값은 반환할 수 없어요.

struct InvalidExamples {
    var _array : [Int]
    
    var local: [Int] {
        borrow {
            let foo = [1, 2, 3]
            //   ERROR: Cannot return local value from borrow accessor
            return foo
        }
    }
    
    var temporary: [Int]? {
        borrow {
            // This would require creating a temporary local
            // optional array from `_array`.
            //   ERROR: Cannot return temporary value from borrow accessor
            return _array
        }
    }
}

반환하는 값은 accessor 실행이 끝난 후에도 유효해야 합니다.

사용 방법

borrow로 읽기

클라이언트 코드는 기존 get과 동일하게 보이지만, 내부적으로는 복사가 일어나지 않습니다.

var owner = Wrapper(value)

// "borrow" the value to give to a function
// without copying...
doSomething(with: owner.element)

func doSomething(with value: borrowing Element) {
    // `value` is borrowed, so this invokes
    // the method "in-place"
    value.someMethod() 

    // Exclusivity prevents the owner from being
    // mutated while `value` is alive:
    owner.mutatingMethod() //   ERROR
}

메모리 일관성을 위해 Swift의 exclusivity rule이 적용됩니다.

borrow가 활성화된 동안엔 owner를 변경할 수 없어요.

mutate로 수정하기

mutate accessor는 읽기/쓰기 접근을 제공합니다.

var owner = Wrapper(value)

// Mutating/inout access will invoke the `mutate` accessor
doSomething(with: &owner.element)

func doSomeMutation(with value: inout Element) {
    // So this invokes a method on the value "in-place"
    // Because you borrowed for mutation, this can be
    // a mutating method.
    value.someMutatingMethod()

    // Accessing the owner is an exclusivity violation
    owner.anyMethod() //   ERROR
}

다른 accessor와의 호환성

mutate를 제공하면

borrow도 반드시 제공해야 함
yielding mutate나 yielding borrow는 사용 불가

Swift는 일반적으로 write-only property를 허용하지 않습니다.

또한 읽기와 쓰기 작업의 접근 scope를 일관되게 유지해야 합니다.

borrow를 제공하면

get이나 yielding borrow는 사용 불가

여러 read accessor나 여러 write accessor를 동시에 정의하면 호출자 입장에서 혼란스럽기 때문입니다.

Ownership 변형

기본적으로 아래와 같아요.

borrow: 포함하는 값을 변경하지 않음
mutate: 포함하는 값을 변경함

이걸 mutating이나 nonmutating 키워드로 오버라이드할 수 있습니다.

mutating borrow

읽기 전용이지만 side-effect로 인해 포함하는 값이 변경될 수 있는 경우입니다.

struct S1 {
  private var cachedValue: Foo
  var foo : Foo {
    mutating borrow {
      if !cachedValue.available {
        // Update `cachedValue`
        // Compiler allows such update
        // because this is `mutating`
      }
      return cachedValue
    }
  }
}

let s1: S1 // Note: Immutable value
s1.foo //   Cannot use mutating accessor on immutable value

캐시를 업데이트하는 경우 같은 거죠.

nonmutating mutate

값을 변경할 수 있지만 부모 값의 변경으로 간주되지 않는 경우입니다.

struct Outer {
  var inner: InnerType {
    borrow {
      return some_value_stored_elsewhere
    }
    nonmutating mutate {
      return &some_value_stored_elsewhere
    }
  }
}

외부에 저장된 값에 접근하는 경우 같은 거예요.

Protocol requirement로 사용

Protocol에서도 borrowing accessor를 요구할 수 있습니다.

protocol BorrowingAccess {
  associatedtype Element
  var element: Element { borrow mutate }
}

이는 두 가지 기능이 있어요.

Protocol을 통한 접근 방식을 제어 (existential이나 generic argument에서)
conforming 타입에 해당 accessor가 있어야 함 (명시적 구현 또는 컴파일러 합성)

컴파일러 합성

Stored property → borrow, mutate 합성 가능
borrow 구현 → yielding borrow나 get 합성 가능 (copyable만)
mutate 구현 → set이나 yielding mutate 합성 가능

제약사항

Protocol이 borrow 요구 → conforming 타입도 borrow 필요
Protocol이 mutate 요구 → conforming 타입은 borrow와 mutate 모두 필요

Class와 Actor에서는 불가

Class는 property 접근 전후로 runtime exclusivity check를 실행해야 합니다.

Borrowing accessor는 접근 후에 코드를 실행할 방법이 없어서 class property에는 사용할 수 없습니다.

yielding borrow와 yielding mutate는 class property에 사용 가능합니다.

Subscript에도 사용 가능

struct ArrayLikeType {
  subscript(index: Int) -> Element {
    borrow { .... }
    mutate { .... }
  }
}

다만 subscript는 전체 struct를 암묵적으로 접근하므로, 아래 코드는 불가능해요.

var x: ArrayLikeType
swap(&x[0], &x[1]) //   두 개의 mutating access

호환성

Source compatibility

기존에 borrow나 mutate라는 이름의 함수를 trailing closure로 호출하는 경우와 충돌 가능성이 있습니다.

struct S {
  func borrow(closure: () -> ()) { ... }
  // Is this a new borrow accessor?
  // Or a call to the borrow method just above?
  var property: Int { borrow { ... } }
}

하지만 실제로는 거의 발생하지 않을 것으로 봅니다.

ABI compatibility

새로운 기능이라 기존 ABI에는 영향이 없습니다.

Adoption 영향

Non-borrowing accessor를 borrowing accessor로 바꾸는 건 일반적으로 ABI-breaking입니다.

하지만 existential type의 ABI는 보존됩니다. (컴파일러가 계속 accessor를 합성할 수 있다면)

Source-breaking일 수도 있습니다. 특히 get을 borrow로 바꾸면 lifetime 제약이 생겨서 기존 코드가 컴파일되지 않을 수 있어요.

향후 방향성

Borrowing returns

함수에서도 borrowed 값을 반환할 수 있으면 유용합니다.

struct S<Value> {
  subscript(_ index: Int) -> Value {
     borrow { ... }
  }
  func indirect(_ parameter: Foo) -> borrowing Value {
     let index = ... compute index from parameter ...
     return self[index]
  }
}

Unsafe pointer를 통한 borrowing

저수준 데이터 구조는 종종 unsafe pointer를 사용합니다.

var _storage: UnsafePointer<Element>

var first: Element {
  borrow {
    // ERROR: borrow accessors can only return stored properties
    // or computed properties that have borrow accessors
    return _storage.pointee
  }
}

이런 케이스를 지원하려면 뭔가 annotation이 필요할 것 같습니다.

var first: Element {
  borrow {
    return unsafeResultDependsOnSelf(_storage.pointee)
  }
}

나왔던 대안

아무것도 하지 않기?

Yielding coroutine-based accessor도 비슷한 기능을 제공하지만, 성능 특성이 다릅니다.

Coroutine accessor는 접근 후에 코드를 실행할 수 있어서 의미론적으로는 더 강력하지만, 완전히 inline되지 않으면 여러 함수 호출 오버헤드가 있습니다.

Borrowing accessor는 여러 함수 호출 오버헤드 없이 in-place mutation 기능을 제공합니다.

Conclusion

특히나 유용한 제안이라고 생각되는 포인트는 non-copyable 타입을 다루는 collection이나 성능이 중요한 저수준 코드에서 큰 도움이 될 것 같아요.

get의 복사 오버헤드와 yielding accessor의 coroutine 오버헤드 사이의 sweet spot을 찾은 느낌입니다.

Swift Standard Library 팀에서도 이 기능을 원했다고 하니, 실무에서 정말 필요한 기능인 것 같네요

References

swift-evolution/proposals/0507-borrow-accessors.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

[Pitch] Borrowing Accessors

I just put up the draft proposal for Borrowing Accessors, which together with Yielding Accessors completes the full suite of accessor support described in the Prospective Vision for Accessors. More complete details are in the draft proposal. The following

forums.swift.org

SE-0507: Borrow and Mutate Accessors

forums.swift.org

[Prospective Vision] Accessors

Hello, Swift Community. The Language Steering Group would like to gather feedback on a prospective vision for accessors in Swift. Vision documents help describe an overall direction for Swift. The actual Swift changes for executing on the vision will come

forums.swift.org