iOYES

[SE-0531] Literal Expressions

GREEN.1229 — Sun, 21 Jun 2026 05:47:30 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0531 — Literal Expressions에 대해 정리해보겠습니다

Intro

Proposal: SE-0531
Authors: Artem Chikin, Doug Gregor
Review Manager: Ben Cohen
Status: Active Review (May 18...29, 2026)

Motivation

Swift에는 정수 리터럴 값만 허용하는 세 가지 문법 컨텍스트가 있습니다.

generic value arguments(SE-0452), @section 변수(SE-0492), enum raw value.

지금까지는 개발자가 직접 값을 계산해서 bare literal로 손수 옮겨 적어야 했어요.

이 과정에서 값이 의미하는 바가 사라지고, 코드 전반에 "매직 넘버"가 퍼지게 됩니다.

@section과 컴파일타임 초기화

@section은 페이지 크기, 레지스터 오프셋처럼 다른 상수로부터 값이 파생되는 시스템/임베디드 환경을 겨냥한 어트리뷰트입니다.

하지만 지금은 연산자나 변수 참조를 전혀 허용하지 않아요.

@section("__DATA,config") let pageSize = 4096
@section("__DATA,config") let bufferSize = 65536
@section("__DATA,config") let c = 1 + 1  // ❌ error: operators not allowed

4096이 4 × 1024라는 사실도, bufferSize가 16 × pageSize라는 관계도 코드만 봐서는 전혀 알 수 없었어요.

Enum raw value

Swift 1.0부터 enum raw value는 순수 리터럴만 허용했습니다. bit-flag enum처럼 shift 표현이 자연스러운 경우조차 표현할 방법이 없었어요.

enum Permissions: Int {
  case read = 1
  case write = 2
  case execute = 4
}
// 1 << 0, 1 << 1, 1 << 2 라고 쓰는 게 훨씬 의도가 명확한데도 불가능했어요

정수 제네릭 인자

SE-0452가 도입한 정수 제네릭 파라미터도 마찬가지로 bare integer literal만 허용합니다.

let schemaRowSize = 32

// 원하는 것: InlineArray<(2 * schemaRowSize), UInt8>
let buffer: InlineArray<64, UInt8>  // 64 == 2 * 32 이길 바랄 뿐...

세 가지 컨텍스트 모두 같은 근본적인 제약을 공유합니다.

개발자가 사람 계산기 역할을 해야 했고, 그 값이 왜 그 숫자인지에 대한 의도는 사라져버렸어요

Proposed Solution

이 제안은 Literal Expression(리터럴 표현식)을 도입합니다.

표준 라이브러리 정수 타입의 리터럴, 산술/비트 연산자, 그리고 컴파일타임에 알려진 다른 정수 변수 참조로 구성된 표현식이에요.

이 표현식은 컴파일 타임에 단일 리터럴 값으로 상수 폴딩됩니다.

// @section — 연산과 변수 참조 모두 가능
@section("__DATA,config") let pageSize = 4 * 1024
@section("__DATA,config") let bufferSize = 16 * pageSize

// enum raw value — shift 표현이 가능
enum Permissions: Int {
  case read    = 1 << 0
  case write   = 1 << 1
  case execute = 1 << 2
}

// 정수 제네릭 — 괄호로 감싼 표현식 허용
let schemaRowSize = 32
let buffer: InlineArray<(2 * schemaRowSize), UInt8>

중요한 점은, literal expression을 사용해 컴파일된 모듈은 개발자가 직접 미리 계산한 리터럴을 쓴 모듈과 완전히 동일한 산출물을 만들어낸다는 거예요.

Detailed Design

Literal Expression의 문법

literal-expression → integer-literal
literal-expression → unary-operator literal-expression
literal-expression → literal-expression binary-operator literal-expression
literal-expression → '(' literal-expression ')'
literal-expression → identifier

지원하는 연산자: 산술(+ - * / %), wrapping(&+ &- &*), 비트(& | ^), shift(<< >>), masking shift(&<< &>>), 단항(+ - ~).

일반 산술 연산자는 오버플로우를 컴파일 타임에 진단하고, wrapping 연산자는 결과를 타입의 비트 너비로 silent하게 모듈러 처리합니다.

let a = 4 * 1024                  // ✅ 산술
let b = 1 << 12                   // ✅ 비트 시프트
let c = (0xFF & mask) | base      // ✅ 비트 연산 + 괄호
let d = -1                        // ✅ 단항 부정
let w: UInt8 = 250 &+ 10          // ✅ wrapping 덧셈, 4로 폴딩
let e = Int.max / 2               // ❌ 프로퍼티 접근 불가
let f = a +% b                    // ❌ 사용자 정의 연산자 불가

연산자 lookup은 Swift의 일반 name lookup 규칙을 그대로 따릅니다. 만

약 lookup이 사용자 정의 오버로드로 해석되면, 표준 라이브러리 오버로드가 스코프에 같이 있더라도 전체 표현식이 거부됩니다.

Literal Expression 내 변수 참조

literal expression은 다른 변수를 이름으로 참조할 수 있습니다.

단, 그 변수가 let 바인딩이고, 기본 초기화 값 자체도 literal expression이어야 해요.

let pageSize = 4 * 1024
let bufferSize = 16 * pageSize             // ✅ pageSize 참조

import CSystem
let systemBuffer = 4 * SYSTEM_PAGE_SIZE    // ✅ C 상수

var mutableSize = 4096
let derived = 2 * mutableSize              // ❌ var는 참조 불가

let computed: Int = { 4096 }()             // ❌ 초기화식이 literal expression이 아님
let derived2 = 2 * computed

주의할 점 — public, package, open 접근 수준의 변수는 literal expression에서 참조할 수 없습니다.

폴딩이 일어나면 해당 변수의 초기화식이 모듈의 ABI 표면에 노출되는 셈인데, 이는 이 제안의 "ABI 변경 없음" 원칙과 충돌하기 때문이에요.

@section 변수 초기화식

@section("__TEXT,config") let pageSize = 4 * 1024
@section("__TEXT,config") let bufferSize = 16 * pageSize
@section("__TEXT,config") let systemPage = PAGE_SIZE    // C 상수

원본 표현식은 진단과 IDE 인덱싱을 위해 AST에 보존되지만, .swiftinterface 파일에는 출력되지 않습니다.

Enum raw value

enum Permissions: UInt8 {
  case read    = 1 << 0    // 1
  case write   = 1 << 1    // 2
  case execute = 1 << 2    // 4
}

enum Example: Int {
  case a = 2 + 2    // 4
  case b            // 5
}

정수 제네릭 인자

generic-argument → type
generic-argument → '-'? integer-literal
generic-argument → '(' literal-expression ')'   // 새로 추가된 형태

제네릭 인자 위치에서는 <, >, , 토큰이 구분자 역할을 하기 때문에, literal expression은 반드시 괄호로 감싸야 합니다.

let schemaRowSize = 32
let buffer: InlineArray<(2 * schemaRowSize), UInt8>    // ✅
let flags: InlineArray<(1 << 4), Bool>                 // ✅
let small: InlineArray<5, Int>                         // ✅ 기존처럼 괄호 없이도 동작

폴딩된 값이 곧 타입 동일성을 결정합니다.

InlineArray<(2 + 3), Int>와 InlineArray<5, Int>는 동일한 타입이에요.

컴파일타임 진단

let x: UInt8 = 100 * 3    // ❌ error: integer overflow
let y = 10 / 0           // ❌ error: division by zero
let z = 10 % 0           // ❌ error: division by zero

@section("__TEXT,data") let a = abs(-1)    // ❌ error: not supported in a literal expression

Source Compatibility

이번 변경은 세 가지 표현식 컨텍스트를 확장할 뿐, 다른 곳에서 받아들여지던 표현식 형태를 제거하거나 바꾸지 않습니다.

흥미로운 케이스 하나는 제네릭 인자 목록의 모호성 해소입니다.

컴파일러는 괄호 안의 내용을 먼저 타입 표현식(튜플)으로 해석을 시도하고, 실패할 때만 literal expression으로 해석합니다.

예를 들어 Foo<(a < b, c > .d)>(x) 같은 코드는 기존의 체이닝 비교 연산으로 폴백되어 의미가 바뀌지 않습니다.

ABI Compatibility

literal expression은 컴파일러 프론트엔드 내에서 완전히 폴딩되며, 코드 생성·런타임·심볼 맹글링에 변화가 없습니다.
정수 제네릭 인자의 경우 폴딩된 값이 모듈 인터페이스에 타입의 일부로 나타납니다 (예: InlineArray<5, Int>).
@section 변수와 enum raw value는 원본 표현식도, 폴딩된 상수도 모듈 인터페이스에 나타나지 않습니다.

Implications on Adoption

이 기능은 LiteralExpressions 실험적 기능 플래그로 게이팅되어 있습니다.

폴딩이 컴파일 타임에 일어나고 생성되는 코드가 직접 작성한 리터럴과 동일하기 때문에, 최소 배포 타겟 제약이 없습니다.

Future Directions

괄호 제약 완화 — 제네릭 인자 위치에서 >, ==, , 를 stop 토큰으로 처리해 InlineArray<2 + 3, Int>처럼 괄호 없이도 파싱 가능하게 만드는 방향
부동소수점 literal expression — Float, Double에 대한 산술 연산 지원
문자열 literal expression — 컴파일타임 문자열 연결 및 보간
비교 연산자 및 표준 함수 지원 확대 — ==, min(), max() 등, 나아가 컴파일타임 Bool을 활용한 삼항 연산자 및 if/else 표현식
컴파일타임 프로그래밍 — SE-0359와 연계해 사용자 정의 순수 함수, 풍부한 데이터 타입까지 포괄하는 일반적인 컴파일타임 프로그래밍 모델로의 확장

Alternatives Considered

참조되는 모든 변수에 명시적 어노테이션 요구

@const 같은 명시적 어노테이션을 요구하는 방식도 고려되었습니다.

하지만 SE-0359 리뷰에서 이런 어노테이션의 "전염성(virality)"이 핵심 우려로 지적된 바 있어요.

literal expression의 경우 어노테이션이 컴파일러가 이미 알고 있는 정보 이상을 제공하지 않기 때문에, 추론만으로 충분하다고 판단해 채택하지 않았습니다.

"Constant Expression" 대신 "Literal Expression" 용어 사용

C/C++의 전통을 따라 "constant expression"이라는 용어를 쓰는 방법도 있었지만, 스코프와 과대 약속의 위험이라는 두 가지 이유로 "literal expression"을 선택했습니다.

Swift가 향후 더 큰 컴파일타임 개념을 도입할 때를 위해 "constant expression"이라는 이름을 아껴두는 것이 합리적이라고 판단했습니다.

Conclusion

지금까지 @section, enum raw value, 정수 제네릭 인자는 모두 "사람이 직접 계산해서 bare literal로 옮겨 적어야 하는" 동일한 제약을 공유하고 있었어요

Literal Expression은 이 세 컨텍스트에 산술·비트·단항 연산과 변수 참조를 허용함으로써, 코드에 값의 의도를 직접 드러낼 수 있게 해줍니다.

그러면서도 컴파일 타임에 완전히 폴딩되기 때문에 ABI나 런타임에는 전혀 영향이 없다는 점이 인상적이에요.

매직 넘버 대신 16 * pageSize, 1 << 2처럼 의미가 드러나는 코드를 쓸 수 있게 되는, 작지만 가독성 측면에서 정말 실용적인 변화라고 생각합니다

References

swift-evolution/proposals/0531-literal-expressions.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-0530] Async Result Support

GREEN.1229 — Sun, 7 Jun 2026 15:09:13 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0530 — Result 타입의 async 이니셜라이저 추가에 대해 정리해보겠습니다

Intro

Proposal: SE-0530
Authors: Konrad 'ktoso' Malawski, Matt Massicotte
Review Manager: Doug Gregor
Status: Implemented (Swift 6.4)

Motivation

Swift의 Result 타입은 throwing 코드를 다룰 때 굉장히 유용한 도구입니다.

기존의 Result.init(catching:)은 throwing 클로저를 Result 인스턴스로 변환해주는 편리한 이니셜라이저예요.

// 기존: 동기 버전은 있음
let result = Result { try syncWork() }

그런데 async 버전이 없었어요. 비동기 작업에서 동일한 패턴을 쓰려면 매번 직접 구현해야 했거든요.

// 지금까지의 불편한 방식 — 코드베이스마다 중복 구현
let result: Result<Data, any Error>
do {
  result = .success(try await asyncWork())
} catch {
  result = .failure(error)
}

어렵진 않지만, 유용성 때문에 많은 코드베이스에서 수동으로 중복 구현되고 있었거든요. 표준 라이브러리가 제공해야 마땅한 패턴이에요!

Proposed Solution

Result.init(catching:)의 async 오버로드를 추가합니다.

이를 통해 아래처럼 간결하게 쓸 수 있게 됩니다.

let result = await Result {
  try await asyncWork()
}

Detailed Design

제안하는 API 변경 사항은 다음과 같습니다.

extension Result where Success: ~Copyable {
  /// Creates a new result by evaluating a throwing closure,
  /// capturing the returned value as a success,
  /// or any thrown error as a failure.
  ///
  /// - Parameter body: A potentially throwing asynchronous closure to evaluate.
  @_alwaysEmitIntoClient
  public nonisolated(nonsending) init(
    catching body: nonisolated(nonsending) () async throws(Failure) -> Success
  ) async {
    do {
      self = .success(try await body())
    } catch {
      self = .failure(error)
    }
  }
}

주요 포인트를 살펴볼게요~!

Success: ~Copyable — noncopyable 타입도 Success로 사용할 수 있습니다.
throws(Failure) — SE-0413의 typed throws를 활용해 Failure 타입을 정확하게 표현합니다.
nonisolated(nonsending) — actor isolation 없이 호출 가능하며, 클로저의 반환값을 안전하게 전달합니다.
@_alwaysEmitIntoClient — 이니셜라이저가 클라이언트 바이너리에 직접 인라인되어 backdeployment가 가능합니다.

Source Compatibility / ABI

이번 변경은 순수 additive 변경으로, 기존 코드에 영향을 주지 않습니다.
@_alwaysEmitIntoClient로 표시되어 이전 Swift 버전으로의 backdeployment가 가능합니다.

Conclusion

아주 작은 변경이지만, 비동기 코드에서 Result를 다루는 패턴이 훨씬 간결해집니다

많은 코드베이스에서 반복적으로 직접 구현해왔던 보일러플레이트를 표준 라이브러리가 흡수해주는 변경이에요.

Result { try await asyncWork() } — 동기 버전과 완전히 동일한 패턴으로 async 작업을 처리할 수 있게 되어, 코드의 일관성도 높아질 것 같습니다

References

swift-evolution/proposals/0530-async-result-support.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-0528] Continuation — Safe and Performant Async Continuations

GREEN.1229 — Sat, 30 May 2026 11:19:40 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0528 — 안전하고 성능 좋은 Async Continuation, Continuation 타입 도입에 대해 정리해보겠습니다

Intro

Proposal: SE-0528
Authors: Fabian Fett, Konrad Malawski
Review Manager: Joe Groff
Status: Accepted with revisions

Motivation

Continuation은 콜백 기반 API를 Swift Structured Concurrency로 연결하는 핵심 메커니즘입니다.

그런데 현재 개발자는 두 가지 옵션 중 하나를 골라야 하는 불편한 선택을 강요받고 있어요.

UnsafeContinuation — 오버헤드는 없지만, 두 번 resume하면 undefined behavior, resume을 빠뜨리면 조용히 task가 영원히 leak됩니다
CheckedContinuation — 런타임 bookkeeping으로 실수를 감지하지만, allocation과 atomic 연산 오버헤드가 발생합니다.

Continuation은 정확히 한 번만 resume해야 하는 "use-exactly-once" 값입니다.

이건 move-only 타입이 강제할 수 있는 계약이에요. 타입 시스템이 이 문제를 해결해야 합니다!

Proposed Solution

Continuation<Success: ~Copyable, Failure: Error>, 즉 ~Copyable struct를 도입합니다. 세 가지 메커니즘으로 올바른 사용을 강제합니다.

Move-only semantics (~Copyable) — continuation을 복사할 수 없으므로, 두 곳에서 resume하는 것이 불가능합니다.
consuming 메서드 — 모든 resume 메서드는 self를 consume해 두 번째 호출은 컴파일 에러가 됩니다.
deinit 트랩 + discard self — resume 없이 continuation이 drop되면 fatalError. 정상 resume 시엔 discard self로 deinit을 억제해 오버헤드가 없어요.

Double-resume — 컴파일 에러로 해결!

actor LegacyBridge {
  func complete(with value: String) {
    if let continuation {
      continuation.resume(returning: value) // ✅ consumes continuation
      continuation.resume(returning: value) // ❌ compile error:
                                            // 'continuation' used after consuming use
    }
  }
}

Missing-resume — 런타임 트랩으로 포착!

actor LegacyBridge {
  func cancel() {
    // Bug: resume 없이 continuation을 지워버림
    self.continuation = nil //   runtime trap: "This continuation was dropped."
  }
}

Detailed Design

Continuation 타입 정의

@frozen
public struct Continuation<Success: ~Copyable, Failure: Error>: ~Copyable, Sendable {

  deinit {
    fatalError("The continuation was dropped without resuming.")
  }

  @inlinable
  public consuming func resume(returning value: consuming sending Success) { ... }

  @inlinable
  public consuming func resume(throwing error: Failure) { ... }
}

Sendable — 다른 task/thread에서 resume할 수 있도록 isolation boundary를 넘을 수 있습니다.
consuming — 각 resume 메서드가 self를 consume해 이후 사용이 불가능해집니다.
sending Success — non-Sendable 값을 async task에 안전하게 전달할 수 있습니다.
consuming Success — noncopyable 타입도 값으로 전달할 수 있습니다.
discard self — 정상 resume 시 deinit을 억제해 오버헤드가 없습니다.

withContinuation — of: 와 throwing: 파라미터

// Before: 클로저 파라미터에 타입 어노테이션 필요
let data = await withCheckedContinuation { (continuation: UnsafeContinuation<Data, Never>) in
  bridge.store(continuation)
}

// After: 호출부에서 타입이 명확하게 보임
let data = await withContinuation(of: Data.self) { continuation in
  bridge.store(continuation)
}

throwing: 파라미터는 SE-0413(typed throws)를 활용해 세 가지 경우를 하나의 함수로 통합합니다.

// Non-throwing
let data = await withContinuation(of: Data.self) { continuation in ... }

// Typed throwing
let data = try await withContinuation(of: Data.self, throwing: NetworkError.self) { continuation in ... }

// Untyped throwing
let data = try await withContinuation(of: Data.self, throwing: (any Error).self) { continuation in ... }

CheckedContinuation으로 변환하기

콜백이 여러 개인 경우처럼 noncopyable Continuation을 사용할 수 없는 경우엔 CheckedContinuation으로 변환해 사용할 수 있습니다.

try await withContinuation(of: Int.self, throwing: (any Error).self) { c in
  let checked = CheckedContinuation(c)
  someLib.onSuccess { checked.resume(returning: $0) } // ✅
  someLib.onFailure  { checked.resume(throwing: $0)  } // ✅
}

이 때문에 CheckedContinuation과 UnsafeContinuation은 deprecated되지 않고 계속 유지됩니다.

동작 비교표

시나리오	UnsafeContinuation	CheckedContinuation	Continuation
정상 resume	✅ 동작	✅ 동작	✅ 동작
Double resume	⚠️ Undefined Behavior	Runtime trap	❌ 컴파일 에러
Missing resume	Silent hang	⚠️ Runtime warning	Runtime trap
런타임 오버헤드	없음	allocation + atomic	없음

Implications on Adoption

Before	After
withCheckedContinuation { … }	withContinuation(of: T.self) { … }
withCheckedThrowingContinuation { … }	withContinuation(of: T.self, throwing: (any Error).self) { … }
CheckedContinuation<T, E>	Continuation<T, E>

단, Continuation은 ~Copyable이기 때문에, 클로저 캡처처럼 continuation을 암묵적으로 복사하는 패턴은 컴파일 에러가 됩니다.

이 경우엔 기존 Checked/UnsafeContinuation을 사용해야 합니다.

Source Compatibility / ABI

이번 변경은 순수 additive 변경으로, 기존 코드에 영향을 주지 않습니다.
withContinuation과 Continuation이라는 이름은 기존 표준 라이브러리 API와 충돌하지 않습니다.
ABI 변경도 없습니다.

Future Directions

~Discardable 프로토콜 도입

현재는 continuation이 drop될 때 런타임 트랩에 의존하고 있지만, ~Copyable 타입을 위한 새로운 모드인 ~Discardable을 도입해 "반드시 명시적으로 consume해야 함"을 컴파일러가 강제하게 할 수 있어요.

이렇게 되면 런타임 트랩마저 컴파일 에러로 격상될 수 있습니다.

Conclusion

드디어 오버헤드 없이 안전한 Continuation이 생겼습니다

기존에는 안전성(CheckedContinuation)과 성능(UnsafeContinuation) 사이에서 트레이드오프를 강요받았는데, move-only 타입의 강점을 활용해 double-resume은 컴파일 에러로, missing-resume은 런타임 트랩으로 잡아주면서 오버헤드는 UnsafeContinuation과 동일하게 유지됩니다.

Swift 타입 시스템의 힘으로 콜백 브리징의 고질적인 버그 두 가지를 완전히 해결한 우아한 변경이라고 생각합니다

References

swift-evolution/proposals/0528-noncopyable-continuation.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-0522] Source-Level Control Over Compiler Warnings

GREEN.1229 — Sat, 23 May 2026 08:45:27 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0522 — 소스 레벨에서의 컴파일러 경고 제어에 대해 정리해보겠습니다

Intro

Proposal: SE-0522
Authors: Artem Chikin, Doug Gregor, Holly Borla
Review Manager: Tony Allevato
Status: Accepted

Motivation

SE-0443에서는 커맨드라인 플래그로 컴파일러 경고를 제어할 수 있게 되었습니다.

예를 들어 -Werror DeprecatedDeclaration을 사용하면 Deprecated 경고를 에러로 격상시킬 수 있죠.

하지만 이 방식은 모듈 전체에 적용되는 블런트한 수단이에요.

특정 선언에서만 예외를 두고 싶은 경우에는 대응할 방법이 없었습니다.

// 모듈 전체에 -Werror DeprecatedDeclaration 적용 중
func bridgeToLegacySystem() {
  oldAPI() //   error: 'oldAPI()' is deprecated [#Deprecated]
}
// 이 함수만 warning으로 낮추고 싶어도 방법이 없었어요

마이그레이션 중인 코드베이스, 레거시 호환성 유지, strict 언어 모드의 점진적 도입 등 현실에서 "딱 이 선언만 예외"가 필요한 순간은 생각보다 많거든요!

Proposed Solution

새로운 선언 어트리뷰트 @diagnose를 도입합니다.

어노테이션된 선언의 렉시컬 스코프 내에서 특정 diagnostic group의 경고 동작을 error, warning, ignored 세 가지 중 하나로 제어할 수 있어요.

기본 문법

@diagnose(group-identifier, as: error | warning | ignored)
@diagnose(group-identifier, as: behavior, reason: "이유")

동작 예시

// 모듈 전체: -Werror DeprecatedDeclaration 적용 중

func normalFunction() {
  oldAPI() //   error
}

@diagnose(DeprecatedDeclaration, as: warning,
           reason: "Must maintain compatibility until end of release cycle")
func bridgeToLegacySystem() {
  oldAPI() //   warning: 'oldAPI()' is deprecated [#Deprecated]
}

ignored로 지정하면 해당 스코프에서 완전히 경고를 억제할 수 있어요.

@diagnose(UnsafeImportedAPI, as: warning)
struct LegacyFormatReader {
  func read(_ data: UnsafeRawPointer, _ count: Int) -> Header {
    c_read_bundle(data, count) //   warning
  }

  @diagnose(UnsafeImportedAPI, as: ignored, reason: "input is validated upstream")
  func readTrustedInput(_ data: UnsafeRawPointer, _ count: Int) -> Header {
    c_read_bundle(data, count) // 진단 없음
  }
}

서브그룹에도 개별적으로 적용이 가능합니다.

// UnsafeImportedOwnership은 UnsafeImportedAPI의 서브그룹
// 모듈 전체: -Werror UnsafeImportedAPI

@diagnose(UnsafeImportedOwnership, as: warning)
func createSession(_ ctx: OpaquePointer) -> Session {
  let session = c_create_session(ctx)
  //   warning: cannot infer ownership ... [#UnsafeImportedOwnership]

  c_bind_session(session, nil)
  //   error: call to imported function ... [#UnsafeImportedAPI]
}

Detailed Design

적용 가능한 선언 종류

@diagnose는 func, struct, class, enum, actor, protocol, extension, init, deinit, subscript, macro, typealias, associatedtype, get/set, willSet/didSet, import, enum case 등 대부분의 선언에 적용할 수 있습니다.

@diagnose(DiagGroupID, as: ignored)
import bar

@diagnose(DiagGroupID, as: ignored, reason: "Proposal Example")
func foo() { ... }

struct Foo {
  var property: Int {
    @diagnose(DiagGroupID, as: ignored)
    get { ... }
    @diagnose(DiagGroupID, as: ignored)
    set { ... }
  }
}

여러 @diagnose 어트리뷰트 — 순서가 중요합니다!

동일한 선언에 여러 @diagnose를 적용할 경우 마지막(렉시컬 순서상 가장 아래)에 있는 어트리뷰트가 우선합니다.

@diagnose(DiagGroupID, as: error)
@diagnose(DiagGroupID, as: warning) // 이 쪽이 최종 적용됨
public func foo() { ... }

Swift 어트리뷰트는 일반적으로 순서 무관하지만, @diagnose는 SE-0443의 커맨드라인 플래그 동작과 일관성을 맞추기 위해 순서가 중요합니다!

-suppress-warnings와의 관계

-suppress-warnings 플래그가 적용된 상태에서는 @diagnose가 완전히 무시됩니다.

as: error를 지정해도 에러로 격상되지 않아요.

이는 SE-0480에서 SwiftPM이 외부 패키지 의존성 빌드 시 경고 관련 플래그를 -suppress-warnings로 대체하는 방식과의 일관성을 위한 것입니다.

매크로와의 상호작용

@diagnose가 적용된 스코프 내에서 매크로가 코드를 생성하면, 그 생성된 코드에도 어트리뷰트의 효과가 적용됩니다.

또한 매크로 작성자가 매크로 확장 코드 안에 직접 @diagnose를 생성할 수도 있어요.

// 매크로 확장 결과물에 @diagnose가 포함될 수 있어요
@diagnose(DeprecatedDeclaration, as: error)
public func endpoint() -> UserProvidedType {
  //   error: 'UserProvidedType' is deprecated [#DeprecatedDeclaration]
}

단, 어트리뷰트가 적용된 선언에 peer 매크로가 붙어 있는 경우, @diagnose의 효과는 peer로 생성된 독립 선언에는 전파되지 않습니다.

Source Compatibility / ABI

이번 변경은 순수 additive 변경으로 기존 소스 호환성에 영향이 없습니다.
ABI에도 영향이 없으며, 텍스트 모듈 인터페이스에도 방출되지 않습니다.
배포 제약 없이 자유롭게 도입하거나 제거할 수 있습니다.

Alternatives Considered

Region-based #pragma 스타일 지시문

Clang 등 C계열 컴파일러처럼 임의 코드 영역에 #pragma clang diagnostic push/pop을 사용하는 방식도 고려되었어요.

하지만 Swift는 메타데이터와 동작을 선언에 귀속시키는 방식을 선호하고, 영역의 끝을 수동으로 관리해야 한다는 점이 복잡한 버그로 이어질 수 있어 채택되지 않았습니다.

매크로 생성 코드에서 @diagnose 금지하기

모든 경고 제어가 개발자 소스 코드에서 명시적으로 보이도록 매크로 확장에서 @diagnose 생성을 금지하는 방법도 고려되었지만, 매크로 작성자가 자신이 생성하는 코드에 대한 진단 정책을 표현할 수 없게 되므로 허용하는 방향으로 결정되었습니다.

-suppress-warnings 하에서도 as: error 적용하기

무조건적인 소스 레벨 에러 격상을 위해 -suppress-warnings 하에서도 as: error를 적용하는 방법도 고려되었지만, SE-0443 및 SE-0480과의 일관성 유지를 위해 채택되지 않았습니다.

Future Directions

로컬 렉시컬 스코프 제어 — do {} 블록처럼 선언이 아닌 임의 스코프에도 적용하는 방향
클로저 표현식 — 특정 클로저 body의 경고 동작 제어
파일 스코프 제어 — using @diagnose(...) 형태의 파일 범위 제어
서드파티 툴 통합 — @diagnose(rule, from: SwiftLint, as: ignored) 같은 형태로 린터 등과의 통합

Conclusion

커맨드라인 플래그로만 가능했던 경고 제어를 소스 레벨의 선언 단위로 세밀하게 다룰 수 있게 해주는 실용적인 변경입니다

마이그레이션 중인 코드베이스, 레거시 호환성 유지, strict 언어 모드의 점진적 도입 등 현실적인 시나리오에서 개발자가 예외의 의도를 코드에 명확하게 문서화할 수 있게 됩니다.

Swift가 더 엄격한 언어 모드와 정적 분석을 강화해가는 흐름 속에서, @diagnose는 그 여정을 훨씬 유연하게 해줄 도구라고 생각합니다

References

swift-evolution/proposals/0522-source-warning-control.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-0523] Hashable conformance for UnownedTaskExecutor

GREEN.1229 — Fri, 15 May 2026 03:53:25 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0523 — UnownedTaskExecutor의 Hashable 채택에 대해 정리해보겠습니다

Intro

Proposal: SE-0523
Authors: Fabian Fett, Konrad Malawski
Review Manager: John McCall
Status: Implemented (Swift 6.4)

Motivation

SE-0417에서 도입된 task executor preferences는 현재 실행 중인 task의 unownedTaskExecutor를 노출해, 성능에 민감한 코드가 executor 기반으로 스케줄링 결정을 내릴 수 있게 해줍니다.

UnownedTaskExecutor는 이미 Equatable을 채택하고 있어요.
그런데 Hashable이 없다 보니, executor를 기준으로 리소스를 인덱싱해야 하는 경우에 불편함이 생겼습니다.

대표적인 사례가 커넥션 풀링입니다.
ConnectionPool이 여러 executor에 걸쳐 커넥션을 관리할 때, task의 executor에 이미 연결된 커넥션을 우선적으로 반환하면 불필요한 컨텍스트 스위치를 줄일 수 있거든요

Hashable이 없으면 executor를 찾기 위해 매번 선형 탐색을 해야 합니다

Before — O(n) 선형 탐색

// Today: O(n) linear search
func pickConnection(preferring executor: UnownedTaskExecutor) -> Connection {
    for (e, connection) in executorConnectionList {
        if e == executor { return connection }
    }
    return executorConnectionList.first!.connection
}

After — O(1) 딕셔너리 조회

// With Hashable: O(1) dictionary lookup
func pickConnection(preferring executor: UnownedTaskExecutor) -> Connection {
    if let connection = connectionsByExecutor[executor] {
        return connection
    }
    return connectionsByExecutor.values.first!
}

이 패턴은 커넥션 풀링뿐만 아니라 executor identity를 기준으로 리소스, 캐시, 스케줄링 메타데이터를 인덱싱하는 모든 시스템에 적용될 수 있습니다.

Detailed Design

UnownedTaskExecutor는 Builtin.Executor 값을 감싸는 struct입니다.
이미 기저 executor 참조의 identity를 기반으로 Equatable 채택이 되어 있어요.

Hashable 채택도 동일한 identity 값을 해싱하므로, 기존 equality 시맨틱과 일관성을 완전히 유지합니다.

extension UnownedTaskExecutor: Hashable {}

API 변경은 이것이 전부입니다. 딱 한 줄이에요

Source Compatibility / ABI

이번 변경은 순수 additive 변경으로, 기존 코드는 변경 없이 그대로 컴파일됩니다.
Equatable을 채택한 타입에 Hashable을 추가하는 것은 소스 호환성을 깨지 않습니다.
프로토콜 채택 추가는 additive ABI 변경이며, 기존 ABI 서피스를 수정하지 않습니다.

Alternatives Considered

아무것도 하지 않기

아무것도 하지 않으면, 개발자가 직접 Hashable 채택을 구현해야 합니다.

extension UnownedTaskExecutor: Hashable {
  @inlinable
  public func hash(into hasher: inout Hasher) {
    let (ident, impl) = unsafeBitCast(self, to: (Int, Int).self)
    hasher.combine(ident)
    hasher.combine(impl)
  }
}

unsafeBitCast를 직접 사용해야 한다는 점에서 불필요하게 위험하고 번거롭습니다. 표준 라이브러리 차원에서 제공하는 것이 당연히 올바른 방향이라고 생각합니다.

Conclusion

아주 작은 변경이지만, 굉장히 자연스러운 확장입니다

Equatable을 채택하고 있는 타입이라면 Hashable도 당연히 지원해야 한다는 Swift의 설계 철학에 맞게, UnownedTaskExecutor도 이제 딕셔너리 키와 Set으로 자유롭게 활용할 수 있게 됩니다!

executor 기반으로 리소스를 관리하는 코드를 작성하고 계신 분들께 특히 반가운 소식일 것 같습니다

References

swift-evolution/proposals/0523-hashable-unownedtask-executor.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-0524] Add withTemporaryAllocation using Output(Raw)Span

GREEN.1229 — Sat, 9 May 2026 13:50:43 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0524 — OutputSpan을 활용한 withTemporaryAllocation 추가에 대해 정리해보겠습니다

Intro

Proposal: SE-0524
Author: Max Desiatov
Review Manager: Doug Gregor
Status: Implemented (Swift 6.4)

Motivation

SE-0322와 SE-0437에서 도입된 withUnsafeTemporaryAllocation은 스택에 임시 메모리를 할당할 수 있는 유용한 API입니다.

하지만 이 함수는 UnsafeMutableBufferPointer 또는 UnsafeMutableRawBufferPointer를 yield하기 때문에, 초기화와 해제를 개발자가 직접 관리해야 했어요.

// 기존 방식 — 수동 관리가 필요해서 실수하기 쉬워요  
withUnsafeTemporaryAllocation(of: Float.self, capacity: 42) { buffer in
  // 초기화, 사용, 해제를 모두 직접 해야 함
  // 에러 발생 시 deinit을 빠뜨리면 버그로 이어짐
}

에러가 발생하는 경우에도 초기화된 요소를 올바르게 해제해야 한다는 점이 특히 까다로웠습니다.

한편, SE-0485에서 도입된 OutputSpan과 OutputRawSpan은 연속적인 메모리 영역의 초기화 상태를 직접 추적하고 관리해주는 타입입니다.

이 두 가지를 결합하면? 안전하고 편리한 임시 메모리 할당 API를 만들 수 있습니다!

Proposed Solution

withUnsafeTemporaryAllocation을 내부적으로 감싸는 새로운 전역 함수 두 가지를 추가합니다.

raw 포인터 대신 inout OutputSpan 또는 inout OutputRawSpan을 yield하는 방식이에요.

타입 지정 할당 (Typed Allocation)

let capacity = 42
let result = try withTemporaryAllocation(
  of: Float.self,
  capacity: capacity
) { output -> Int in
  for i in 0..<capacity {
    output.append(i)
  }

  var mutableSpan = output.mutableSpan
  updateInPlace(&mutableSpan)

  return aggregate(output.span)

  // 클로저가 끝나면 OutputSpan이 자동으로 해제됩니다
}

Raw 바이트 할당 (Raw Bytes Allocation)

let byteCount = 16

let result = try withTemporaryAllocation(
  byteCount: byteCount,
  alignment: 4
) { rawSpan -> Int in
  rawSpan.append(repeating: 0, count: byteCount, as: UInt8.self)

  var mutableBytes = rawSpan.mutableBytes
  updateInPlace(&mutableBytes)

  return aggregate(rawSpan.bytes)

  // OutputRawSpan은 클로저 종료 시 자동으로 해제됩니다
}

Detailed Design

두 함수의 시그니처와 내부 동작을 살펴볼게요~

① withTemporaryAllocation(of:capacity:) — OutputSpan

@available(SwiftCompatibilitySpan 5.0, *)
@export(implementation)
public func withTemporaryAllocation<T: ~Copyable, R: ~Copyable, E: Error>(
  of type: T.Type,
  capacity: Int,
  _ body: (inout OutputSpan<T>) throws(E) -> R
) throws(E) -> R where T: ~Copyable, R: ~Copyable {
  try withUnsafeTemporaryAllocation(of: type, capacity: capacity) { (buffer) throws(E) in
    var span = OutputSpan(buffer: buffer, initializedCount: 0)
    defer {
      let initializedCount = span.finalize(for: buffer)
      span = OutputSpan()
      buffer.extracting(.<initializedCount).deinitialize()
    }
    return try body(&span)
  }
}

내부 동작 흐름은 다음과 같습니다.

Allocation — withUnsafeTemporaryAllocation(of:capacity:)로 초기화되지 않은 타입 버퍼를 확보합니다.
Span Creation — initializedCount: 0으로 OutputSpan을 생성합니다.
Execution — OutputSpan을 inout 파라미터로 클로저에 전달합니다.
Cleanup — defer 블록에서 finalize(for:)로 초기화된 요소 수를 파악하고, deinitialize()로 정리합니다.

② withTemporaryAllocation(byteCount:alignment:) — OutputRawSpan

@available(SwiftCompatibilitySpan 5.0, *)
@export(implementation)
public func withTemporaryAllocation<R: ~Copyable, E: Error>(
  byteCount: Int,
  alignment: Int,
  _ body: (inout OutputRawSpan) throws(E) -> R
) throws(E) -> R where R: ~Copyable {
  try withUnsafeTemporaryAllocation(byteCount: byteCount, alignment: alignment) { (buffer) throws(E) in
    var span = OutputRawSpan(buffer: buffer, initializedCount: 0)
    defer {
      _ = span.finalize(for: buffer)
      span = OutputRawSpan()
    }
    return try body(&span)
  }
}

OutputRawSpan은 raw 바이트를 다루며 BitwiseCopyable로 간주되기 때문에, OutputSpan과 달리 deinitialize() 호출이 필요 없습니다.
임시 메모리는 자동으로 해제됩니다.

Source Compatibility / ABI

이번 변경은 순수 additive 변경으로, 기존 코드에 영향을 주지 않습니다.
두 함수 모두 @export(implementation)으로 표시되어 클라이언트 바이너리에 직접 인라인됩니다.
표준 라이브러리의 새로운 ABI 엔트리 포인트가 아닌, 기존 ABI를 활용하는 방식이라 ABI 호환성에도 영향이 없습니다.

Alternatives Considered

아무것도 하지 않기

기존 withUnsafe... 변형을 계속 사용하고 개발자가 직접 OutputSpan/OutputRawSpan으로 감싸는 방법이 있어요.
하지만 동일한 보일러플레이트 코드를 반복해야 하기 때문에, 이번 제안처럼 표준 라이브러리에서 제공하는 것이 적절하다고 판단했습니다.

OutputSpan / OutputRawSpan의 static 메서드로 추가하기

각 span 타입의 static 메서드로 만드는 방법도 고려되었지만, withUnsafeTemporaryAllocation이나 withExtendedLifetime 같은 기존 전역 함수 패턴과 일관성을 유지하기 위해 전역 함수로 채택했습니다.

Future Directions

현재 제안은 주요 안전 래퍼를 다루고 있으며, 향후 async 오버로드도 고려할 수 있어요.

다만 async 오버로드는 이 함수만을 위한 게 아니라 표준 라이브러리의 with 스타일 함수 전체에 걸쳐 일관되게 추가되어야 한다고 보고 있습니다.
또한 suspension point에서의 할당은 힙 메모리를 사용하게 되어, 스택 할당의 이점이 사라진다는 점도 고려 중이에요.

Conclusion

withUnsafeTemporaryAllocation과 OutputSpan/OutputRawSpan의 강점을 결합한 실용적인 변경입니다

기존에는 임시 메모리 할당 시 raw 포인터를 직접 다루며 초기화/해제 관리까지 책임져야 했는데, 이번 제안으로 안전하고 간결하게 임시 메모리를 사용할 수 있게 됩니다.

특히 unsafe API에 익숙하지 않은 개발자도 스택 할당 임시 메모리를 부담 없이 활용할 수 있게 된다는 점에서 진입 장벽을 낮추는 변경이라고 생각합니다

References

swift-evolution/proposals/0524-span-temporary-allocation.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-0521] Improved Syntax for Optionals of Opaque and Existential Types

GREEN.1229 — Fri, 1 May 2026 06:51:10 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0521 — Opaque 및 Existential 타입의 Optional 문법 개선에 대해 정리해보겠습니다

Intro

Proposal: SE-0521
Author: Tony Allevato
Review Manager: Frederick Kellison-Linn
Status: Accepted with modifications

Motivation

Swift에서 some P와 any P는 이미 익숙한 문법이죠.

개발자들은 자연스럽게 Int?, String?처럼 some P? 또는 any P?라고 쓰고 싶어 합니다.

그런데 현재 이 코드는 컴파일 에러가 발생합니다

func fetchUser() -> some Identifiable?  // ❌ error
var handler: (any EventHandler)?        // ✅ 이렇게 써야 함
var handler: any EventHandler?          // ❌ error

이유는 파싱 우선순위 때문입니다.

컴파일러는 some P?를 some (P?)로 해석하는데, Optional<P>는 프로토콜이 아니기 때문에 에러가 발생하게 됩니다.

결국 개발자들은 어쩔 수 없이 (some P)?, (any P)?처럼 괄호를 추가해서 써야 했어요.

커뮤니티에서도 "ExistentialAny를 적용하고 나서 괄호 때문에 가독성이 너무 떨어진다"는 불만이 꽤 많았던 주제였거든요!

Detailed Design

이번 제안의 핵심은 간단합니다.

some P?와 any P?를 각각 (some P)?, (any P)?와 동일한 의미로 허용하는 것입니다.

기본 동작

some P?  // == (some P)?  ✅
any P?   // == (any P)?   ✅
any P!   // == (any P)!   ✅

다중 Optional도 지원

var a: some P??  // == (some P)??
var b: any P???  // == (any P)???

파서는 변경 없음

some P?는 여전히 OpaqueResultTypeRepr(OptionalTypeRepr(P))의 형태로 파싱되며, TypeRepr(AST) 자체도 바뀌지 않습니다. 단지 타입 체커가 이 구조를 만났을 때 의미를 재해석하는 방식만 바뀌는 것입니다.

함수 파라미터에서도 동작

func process(_ item: some Identifiable?) { }
// == func process<T: Identifiable>(_ item: T?) { }

Fix-it도 개선

// Before fix-it
let x: P?
// warning: ... fix-it → (any P)

// After fix-it
let x: P?
// warning: ... fix-it → any P  (괄호 없음!)

주의: 프로토콜 컴포지션은 여전히 괄호 필요

// ❌ 여전히 에러: P & Q? 자체가 invalid
var x: some P & Q?

// ✅ 이렇게 써야 합니다
var x: (some P & Q)?

// ✅ typealias 활용도 가능
typealias PQ = P & Q
var x: some PQ?  // OK!

Accepted with modifications

Language Steering Group은 원 제안에 수정 사항을 추가해 승인했습니다.

바로 suppressed constraints(~)에도 동일한 개선을 적용하는 것입니다.

any ~Copyable?   // == (any ~Copyable)?  ✅
some ~Copyable?  // == (some ~Copyable)? ✅

var x: ~Copyable?  // ⚠️ warning: requires 'any'

단, .swiftinterface 파일에는 기존처럼 괄호를 포함한 형태((any P)?)가 유지됩니다.

해당 파일은 컴파일러가 소비하는 아티팩트이지, 개발자가 직접 읽는 용도가 아니기 때문이에요.

Source Compatibility / ABI

이번 변경은 순수 additive 변경으로, 기존 코드와의 소스 호환성은 100% 유지됩니다.
기존의 (some P)? 형태는 여전히 유효합니다.
some/any P?와 (some/any P)?의 타입 맹글링은 동일하므로 ABI에도 영향이 없습니다.

Alternatives Considered

아무것도 하지 않기

괄호 방식을 그대로 유지하는 것도 방법이지만, ExistentialAny가 언젠가 필수가 된다면 코드베이스 전반에 걸쳐 괄호가 대량으로 생겨나는 문제가 있거든요.

제안자는 이를 미리 해결하는 것이 적절하다고 판단했습니다.

Conclusion

작은 변경이지만, any/some 타입을 자주 쓰는 코드베이스에서는 가독성이 꽤 많이 개선되는 실용적인 변경입니다

Int?를 쓰듯이 any Protocol?, some Protocol?을 자연스럽게 쓸 수 있게 되면서, Swift의 타입 시스템이 한층 일관적이고 직관적으로 느껴지게 될 것 같습니다!

특히 ExistentialAny를 이미 적용한 프로젝트에서는 산더미 같은 괄호들을 제거할 수 있겠네요

References

swift-evolution/proposals/0521-improved-optional-opaque-and-any.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-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