Swift 5.2 Released!

 

안녕하세요 :) Zedd입니다.

자고 일어나니..!! Swift 5.2가 나왔네요.

공-식 릴리즈 노트를 한번 훑어보려고 합니다 :D

중간중간 번역 안한 부분도 있으니 참고해주세요. 

 

Swift 5.2 Released!

2020년 3월 25일 수요일 Swit 5.2가 공식적으로 출시되었습니다 🎉

Swift 5.2는 Xcode 11.4의 일부로 제공됩니다. 그러니 사용하려면 11.4를/...

 

먼저 Language Updates부터 보겠습니다.

• SE-0249 Key Path Expressions as Functions

• SE-0253 Callable values of user-defined nominal types

이렇게 2개를 넣어놨네

첫번째거부터 볼게요. 

"Key Path Expressions as Functions"

제목이 말 다 했다...위 링크에 다 나와있긴 한데.. 한번 볼게요!

이런 struct가 있을 때

User타입이 들어있는 collection에 대해

 

users.map { $0.email }

users.filter { $0.isAdmin }

 

이렇게 쓸 수 있잖아요?

proposal에 뭐라 적혀있냐면 

이런 짧고 스윗한...closure도 좋지만..Swift는 이미 더 짧고 더 스-윗한 구문이 있자나..

바로 key paths얌

그래서 결국 이렇게도 할 수 있게 되었습니다. 

 

users.map(\.email)은 

users.map { $0[keyPath: \User.email] }

와 같습니다. 

 

두번째 proposal. 이건 Xcode 11.4 Beta Release Notes 에서 본거긴 한데..일단 볼게요!

Swift에 정적으로 호출 가능한 값(statically callable values)을 도입했다고 해요. 

타입이 아주 특정한 이름인.."callAsFunction"이라는 메소드를 구현하는 경우, 값을 직접 호출 할 수 있게 됩니다. 

자 Adder인스턴스에 그냥 정말 정적으로 함수를 호출할 수 있게 되었습니다.

원래같으면 add3.callAsFunction(10) 이렇게 호출해야 했을 텐데요.

그냥 add3(10)이렇게 호출 할 수 있게 된거죠.

중복된 메소드만 아니면(리턴을 다르게, 파라미터를 다르게) 여러개가 있어도 상관없어요~

 

proposal을 읽다가..구현 방법이 간단하고 재밌어서 소개하려고 해요zz

구현은 매우 간단하며, type checker에서 lookup 및 expression rewrite을 수행하는 200줄 미만의 코드라고 해요!

add1(0)은  결국에는 add1.callAsFunction(0)으로 다시 쓰여지는 것!

 

 

그럼 이정도로만 보고 다음으로 넘어갈게요!

이번 릴리즈는 developer experience 향상에 중점을 둡니다. (오..."DX"라고 하면 되는건가)

 

- 향상된 컴파일러 진단(에러 및 경고), code completion

- 디버깅 안정성 향상

- SPM에서 향상된 종속성 처리

- LSP 및 SwiftSyntax를 통한 툴링 개선

 

Improved Compiler Diagnostics

위에서 언급했듯이, Swift 컴파일러에서 오류 메세지의 품질과 정밀도가 크게 향상되었습니다!

먼저 expression이라는 말이 나올텐데요.

이 expression이 뭔지! 알고 읽으면 더 좋을 것 같아서 이 expression에 대한 설명을 간락하게 하고자 합니다.

expression을 평가하면(Evaluate) 값이 반환되거나 side effect가 발생하거나, 아니면 둘 다 발생한대요!

그러니까 expression은 값을 반환하거나, side effect가 발생하거나 또는 둘 다에 해당하는 코드라고 말할 수 있겠습니당.

 

자, 그래서 이전에는 컴파일러가 subexpression에서 개별적으로 failures를 검색하기 위해 expression을 분리하여 오류의 정확한 위치를 추측하려고 했었대요..! 

이는 parent expression에 대한 정보를 사용하지 않고, 오류의 위치를 단일 subexpression으로 좁힐 수 있는 경우에는 효과적이었지만

이 전략으로는 정확하게 식별할 수 없는 수많은 종류의 프로프래밍 실수들이 있었대요.

이제 컴파일러는 expression에서 타입을 유추하면서, failures가 발생하면 "breadcrumbs(빵 부스러기)"를 남기고, 모든 특정 failures를 기록합니다.

이러한 이동경로를 통해 컴파일러는 정확한 진단을 생성하여 개발자가 올바른 코드를 찾을 수 있도록 한다고 합니다.

이런 코드가 있다고 했을 때, 

enum E에는 case three가 없으니 에러가 나겠죠?

Swift 5.1에서의 위 코드는 

error: binary operator '!=' cannot be applied to operands of type 'E' and '_'

라는 에러가 뜬대요.! 

Swift 5.2에서는

똑똑하고 정확하게 에러가 나는 이유를 말해주네요. 

그 외에도 SwiftUI에서 오류가 나는 코드와 전혀 상관이 없던 코드에 에러메세지를 보여주던 이슈도 해결되었다고 하니 참고하세요..!

 

Code Completion Improvements

이제부터 불필요한 타입 검사를 제거해서 더 빠른 completion을 제공한다고 합니다.

Xcode 11.3.1과 비교해서 code completion이 1.2 ~ 1.6배까지 빨라질 수 있다고 해요. 💕 

 

이제 incomplete(불완전한..?) dictionary literals 과 incomplete ternary expressions에 implicit(암시적) 멤버의 이름을 제공할 수 있다고 합니다.

출처 : https://swift.org/blog/swift-5-2-released/

 

그리고 타입이 결과에 나타날 때 더 쉽게 읽을 수 있게 바뀌었다고 합니다.

가능한 경우 opaque result types (e.g. some View)를 사용하고, typealiases를 유지합니다.

필요하지 않은 경우 parent types을 보여지는걸 중지했습니다. 

뭔말이야;; 그림 보면 앎

Swift 5.1이구요

 

아래가 Swift 5.2입니다. 

깔-끔

 

Improved Build Algorithms

Swift 컴파일러는 두가지 작동 모드를 지원하죠.

- Whole Module (일반적으로 Release builds에 사용됨). 

- Incremental(증분) (일반적으로 Debug builds에 사용됨.)

 

Xcode에서는 Swift프로젝트 빌드 설정에서 볼 수 있습니다. 

이 2가지 모드는 컴파일 속도와 코드 최적화 양(amount)이 서로 tradeoffs됩니다.

증분빌드는 프로젝트의 모든 파일을 다시 컴파일 할 필요가 없는 개발과정에서 유용하며, 최대 최적화가 중요하지 않습니다.

전체 모듈 최적화는 컴파일러가 전체 코드 베이스 전체를 더욱 완벽하게 파악할 수 있으므로 최적화 능력이 향상됩니다. 

 

증분 모드 빌드에서, 모듈 재빌드 작업은 병렬로 실행되는 여러 컴파일 작업으로 나뉩니다.

재빌드 된 모든 소스 파일에 대해, 해당 소스 파일의 선언(declarations)에 대한 타입 검사 및 코드 생성을 담당하는 연관된 컴파일 task가 정확히 하나 있습니다. 

ㅇㅋ...

Swift 선언(declarations. functions, properties, types같은 것들)은 소스 파일에서 서로를 참조할 수 있기 때문에 때때로 다른 소스파일에서 declarations의 타입 체크를 해야하는 일이 생길 수 있죠.

이러한 파일간 declarations 참조는 증분 모드 빌드의 효율성을 떨어뜨릴 수 있습니다.

이는 컴파일 작업에서 타입 검사 작업을 복제할 수 있기 때문입니다.

맞어맞어..

 

반대로 전체 모듈 컴파일은 모듈의 모든 코드를 하나의 컴파일 작업으로 처리해서 작동한다고 합니다.

컴파일 작업에서 타입 검사 작업이 중복되지는 않지만, 모듈에서 코드를 컴파일 할 때 병렬처리는 없습니다. 

그러나 전체 모듈 컴파일은 컴파일러가 모듈의 코드를 한 번에 더 많이 볼 수 있게 하여 더 많은 코드 최적화를 가능하게 합니다.

 

자 잘 읽으세여ㅛ

위에서 말했듯이, 증분 빌드 같은 경우에 타입 검사 작업이 복제 된다고 그랬잖아요 (=타입 검사 작업이 중복될 수 있음)

그래서, 증분빌드는 빌드 시간 이점이 젤 봐줄만한 친구인데 ㅡㅡ

각 컴파일 작업이 수행하는 중복 작업의 양에 의해 이 빌드 시간 이점이 줄어들겠죠. 

이 중복된 작업이 너무 많으면 증분 모드가 전체 모듈 컴파일보다 더 많은 작업을 할 수도 있다고 합니다. 😱

오버헤드가 프로세서 코어 수를 초과하지 않는 한, 증분 모드 빌드는 여전히 전반적으로 빠를거지만, 이 오버헤드를 줄이는 것은 빌드시간을 개선하는 데 핵심이죠!!!

 

아 적으면서 그래..맞지...어 맞아...어!! 맞아맞어....ㅁㅈㅁㅈ..아니 이거 어케좀 해봐..이러면서 적ㄴ는 중

 

Making Incremental Builds more Efficient

Apple : 증분 빌드를 보다 효율적으로 만들어보쟈 

증분 모드 빌드에서 수행되는 낭비되는 작업을 최소화하기 위해 Swift 5.2컴파일러(특히 type checker)는 요청(request)간 캐싱, lazy evaluation(지연 평가), 종속성 추적을 위해 새로운 중앙 집중식 로직(new centralized logic)을 활용한다고 합니다. 

이 로직은 컴파일러에서 declarations과 서로에 대한 참조를 보다 효율적으로 해결하는데 사용된다고 합니다.

Swift 5.2 이전에는 다른 소스 파일에서 declarations이 참조 될 때 type checker가 이 declarations에 대해 "validation(유효성 검사)" 라고 하는 작업을 명시적으로 수행했다고 합니다.

유효성 검사는 변경 가능한 상태(mutable state)를 사용했으며, 코드 생성 중에 나중에 필요할 수 있는 declarations의 여러 프로퍼티를 미리 계산하려고 시도하면서..다소 "거칠었다고" 합니다. 

이렇게 열심히 사전에 정보 계산하는건 종종 불필요하고 낭비가 될 수 있단 마랴

Swift 5.2에서는 컴파일러에서 declarations 내부 표현은 불변이며(immutable), 컴파일러 코드 생성 단계에서 request의 lazy evaluation 를 트리거 할 수 있으며 결과는 캐시됩니다. (먼소리지)

request는 이전의 유효성 검사 단계보다 세분화되므로 작업 낭비를 방지하여 성능을 향상시킵니다.

또한 type checker가 유효성 검사를 할 필요 없는 것들에 대한 정확성 문제를 수정했다고 해요. 간단하게 말해서 불필요한 유효성 검사를 안하도록 했다 라고 생각하면 될 듯.

 

Additional Improvements

향상된 증분 빌드 외에도 Swift 5.2 컴파일러에는 기본 구성 요소에 대한 여러가지 성능 최적화 기능이 포함되어 있다고 합니다. 

(name lookup이 뭔지 아시는 분..? 여기서 나오는데 뭔소린지 몰라서 번역 안함ㅎ)

이러한 개선으로 Whole Module /  Incremental mode builds 대한 빌드시간이 향상될 것으로 예상됩니다.(expect) 뭐 예상..?

이러한 변경사항은 name lookup내부의 다양한 알고리즘(big-O) 복잡성을 줄이므로

특히 소스 파일이 많은 대규모 프로젝트에 도움이 된다고 합니다.

 

Debugger Improvements

Swift 디버깅이 지원되는 모든 플랫폼에서 LLDB는 이제 디버그 정보에서 Swift 프로그램의 타입 정보를 재구성하는데 더욱 복원력이 높다고 해요. 

이 복원력은 디버거가 Swift타입에 대한 자세한 정보를 사용할 수 있도록 합니다.

특히 LLDB는 소스 코드에서 Clang 모듈을 컴파일 하는 대신 DWARF debug정보에서 C 및 Objective-C타입을 가져올 수 있다고 해요.

이 동작은 symbols.use-swift-dwarfimporter 로 제어할 수 있다고 합니다. 기본적으로 이 설정은 기존 Clang 모듈 import가 실패 할 때 대체경로로 사용된다고 합니다. 

 

Swift Package Manager

Swift 5.2의 SPM(Swift Package Manager)에는

- tool version 5.2 이상이 포함된 remote Swifgt 패키지는 더 이상 테스트 target에만 사용되는 패키지 종속성을 해결하지 않으므로 성능을 향상시키고, 종속성 버전 충돌 가능성을 줄입니다... @_@ 뭔소리지

- SPM은 새로운 전략을 사용하여 복잡한 패키지 그래프에서 오류 메세지의 품질과 성능을 크게 향상시킵니다. 

 

이정도로만 볼게요 :D

더 자세한 내용은 https://swift.org/blog/swift-5-2-released/

Swift 5.2 Released!

를 참고해주세요 ~.~

 

이번 글은 좋은게 원인 - 해결 이런식으로 글을 써주셔서 이해가 더 잘된 것 같아요 ㅎㅎㅎ

특히 Improved Build Algorithms 부터..!!

어떤 부분이 문제를 야기하고, 어떻게 해결해야하는지 차근차근 설명해주셔서 읽으면서 감동받음..

그동안에 나왔던 Swift 릴리즈 노트들을 대충 보니까 5.2 처럼 길지도 않고..원래

 

- 뭐 됐음

- ㅁㅝ 돼ㅔㅆ음

- 이것도 추가됨

 

이런 느낌이었는데....

저는 그래서 아 다른 사람이 썼나? 하고 봤더니 늘 똑같은 사람이 썼네요 ㅎㅎ...

아무튼 저한테 너무 도움된 글이었던 것 같아요 ㅎㅎ

다른 분들에게도 도움이 되었길 바랍니다. XD