Initialization / Accessors proposals → property model 교차 읽기¶

이 페이지는 swift/docs/proposals/Initialization.rst와 swift/docs/proposals/Accessors.rst를 현재 Swift의 initializer 규약, property model, writeback, memory access, SIL 관점으로 다시 읽는 교차 페이지다.

왜 이 두 proposal을 같이 봐야 하나¶

겉으로 보기엔 - 하나는 초기화(init) - 하나는 accessor/getter/setter 문서처럼 보인다.

하지만 실제로 둘은 같은 큰 문제를 만진다.

객체와 값이 언제 “완전히 초기화된 것”인가?
property / subscript 접근을 getter/setter로만 모델링하면 어떤 비용이 생기는가?
writeback, inout, COW, subobject access, definite initialization은 어떻게 이어지는가?

즉 이 두 문서는 현재 Swift property model과 메모리 접근 모델의 역사적 배경이다.

Initialization.rst의 핵심 포인트¶

1. two-phase initialization¶

문서는 Swift의 class initialization을 두 단계 초기화 모델로 본다.

핵심 포인트: - subclass stored property를 먼저 초기화 - 그 다음 super.init - peer delegation과 superclass delegation을 구분 - partially initialized object 정리를 명시적으로 다룸

이건 현재 다음 페이지와 직접 이어진다.

2. initializer inheritance / virtual initializer 문제¶

이 proposal은 initializer inheritance, peer delegation, protocol requirement initializer, ObjC entrypoint와 dynamic dispatch 문제를 꽤 넓게 다룬다.

오늘날 세부 구현은 proposal 당시와 달라졌더라도, “initializer는 단순 함수가 아니라 object construction rule”이라는 감각은 그대로 중요하다.

3. Objective-C interop와 초기화 모델 충돌¶

문서의 흥미로운 점은 Swift 초기화 soundness와 ObjC initialization entrypoint의 차이를 함께 본다는 점이다. 그래서 initialization proposal은 순수 init 문서가 아니라 interop 문서이기도 하다.

Accessors.rst의 핵심 포인트¶

1. getter/setter만으로는 부족하다¶

이 문서는 abstract storage access를 full-value load/store만으로 처리하면 생기는 문제를 아주 길게 분석한다.

대표 문제: - subobject clobbering - writeback 비용 - abstraction barrier 때문에 optimizer가 보수적이 됨 - COW 값에서 구조적 복사가 강제됨

즉 accessors proposal은 현재 SIL 메모리 접근 모델와 Value Semantics / COW proposals → ownership/runtime 교차 읽기로 이어지는 핵심 역사 문서다.

2. property model은 성능 문제이기도 하다¶

문서는 property / subscript / abstract storage를 단순 문법 설계가 아니라 optimization / aliasing / memory safety 문제로 다룬다.

특히 다음 축과 강하게 연결된다. - SIL 메모리 접근 모델 - SIL 소유권 모델 (OSSA) - 표준 라이브러리·런타임·컴파일러의 관계

3. resilient / abstract / overridable storage 문제¶

문서는 protocol member, non-final class member, resilient declaration처럼 구현을 정적으로 알 수 없는 storage를 보수적으로 접근해야 한다고 본다. 이 점은 ABI / resilience / accessor design을 같이 보게 만든다.

현재 구현과 어떻게 이어 읽으면 좋은가¶

initialization 축¶

storage / access 축¶

stdlib/runtime 축¶

로컬 Swift 소스에서 같이 볼 경로¶

swift/docs/proposals/Initialization.rst
swift/docs/proposals/Accessors.rst
swift/docs/SIL/SILInitializerConventions.md
swift/docs/SIL/SILMemoryAccess.md

현재 위키 연결: - 실패 가능한 이니셜라이저 (init?) - SIL 초기화 규약 - SIL 메모리 접근 모델 - SIL 소유권 모델 (OSSA) - 타입 체커 설계 및 구현

이 문서를 읽을 때 주의할 점¶

proposal의 세부 syntax/attribute 제안이 지금과 동일하다고 보면 안 된다.
하지만 “초기화와 storage access를 soundness + performance 문제로 본다”는 핵심은 지금도 그대로 중요하다.
그래서 현재 구현 페이지와 같이 읽을 때 가치가 크다.