Swift의위험 신호인가요?

Swift Tweets 2018 Spring에 발표된'！나 이제 알았어!의 내용을 Qita 대상으로 대폭 수정한 것이다.
LT가 5분(약 10분)이고 트위터의 글자수 제한이라고 오해해 발표할 때 충격성을 중시한다고 판단해 촘촘하게 정리1했다.
원래 게시된 트윗은 이 목록의 스레드입니다.
https://twitter.com/hironytic/status/985163326530310146
Swift Tweets 2018 Spring에 대한 Togetter의 요약은 다음과 같습니다.
https://togetter.com/li/1218153

try! 스위프트부터 한 달이 지났어요.

궁금한 게 하나 있는데.매년 try! Swift 개최할 때마다그래서 위험한 단락이 등장하는 거야.나는 소재 자체가 매우 좋다고 생각한다.try? 나는 스위프트면 될 것 같아, 캣츠 같은 거, 스위프트와 관련된 느낌이 좋아.그런데 ! 위험해요?
확실히 이 기호는 경고를 표시하는 것이다. 나는 이것이 좀 무섭다는 것을 안다.그래서 나도 !가 직관적인 위험 신호라는 것을 안다.그렇다면 스위프트try!와 옵티올의forced unwrapping!)은 정말 위험한가?

조사해 보았다

사과The Swift Programming Language에 이렇게 쓰여 있다2.
forced unwrapping 정보는 이런 기술이다.
Once you’re sure that the optional does contain a value, you can access its underlying value by adding an exclamation mark ( ! ) to the end of the optional’s name. The exclamation mark effectively says, “I know that this optional definitely has a value; please use it.” This is known as forced unwrapping of the optional’s value:
"이 Optional은 의심할 여지없이 가치가 있다. 그걸로 하자"는 Exformation 로고는 이 점을 효과적으로 나타냈다.
try! 정보 그렇죠.
Sometimes you know a throwing function or method won’t, in fact, throw an error at runtime. On those occasions, you can write try! before the expression to disable error propagation and wrap the call in a runtime assertion that no error will be thrown.
함수와 방법이 예외가 아니라는 것을 알았을 때 사용하거나 오류가 발생하지 않는 운행 시간 분배에 호출을 포함합니다.

사실!위험해요?

이런 예를 생각해 보아라.

let numbers = [10, 20, 30]
let x = numbers.first!

first는 그룹이 비어 있을 때 nil을 되돌려줍니다.진열이 비어 있지 않다는 것을 알기 때문에 이것!은 안전하다.
사회적으로!는 사악한 것이기 때문에 가능한 한 피하는 사람도 있다.사실 나도 예전에 이렇게 생각했다.하지만 @koher씨에게 말씀드리고 나니 생각이 좀 바뀌었습니다.그의 글'Swift 오류 4가지 너무 좋아요.에서 쓴 것처럼 forced unwrapping은 Swift의 4가지 잘못된 Logic Failure에 해당한다.
즉, 방금 전의 코드는 이렇게 쓴 것이다.
반대로 이런 코드를 간단하게 쓸 수 있다!고도 할 수 있다.

guard let x = numbers.first else {
    // こんなことが起こってはいけない
    preconditionFailure("numbers should have first element")
}

버그로 인해 전제조건이 성립되지 않으면 프로그램이 종료됩니다3.사용자 입장에서 볼 때 붕괴는 가장 이해하기 쉬운 오류이다.그리고 하고 싶은 일을 방해하는 가장 큰 물건으로 사용자 체험을 망친다.이를 피하기 위해 preconditionFailure 등 단순 패싱 처리를 사용하는 방법도 있다.

guard let x = numbers.first else {
    // こんなことが起こってはいけないが念のため
    return
}

그럼 안 떨어질 거야.하지만 발생할 수 없는 이상계를 찾기는 어렵다.사용자는 하고 싶은 일을 할 수 있지만, 실제로 건너뛴 처리는 데이터의 통합성을 흐트러뜨릴 수 있다.며칠이 지나 절차의 다른 곳에서 문제가 발견됐을 때 원인을 따지는 것은 대원을 건너뛴 것일 수 있어 어려울 수 있다.또 다수의 사용자 데이터의 일치성이 흐트러져 큰 혼란을 일으키면 그 전에 붕괴하는 것이 좋다.
전자는 문제를 검출할 수 있으나 붕괴되고, 후자는 문제를 검출할 수 없지만 붕괴되지 않는다.어느 것이 좋은지에 관해서는 절차마다 성질이 다르기 때문에 일률적으로 논할 수 없다.return 위험해요?이 문제에 대해 버그가 있다면 이곳에서 붕괴될 위험이 확실히 있지만 버그가 문제를 일으킬 위험성은 이에 국한되지 않는다!.

! 위험 신호 아니에요.

내가 얻은 결론은 스위프트의!는 위험 신호가 아니라는 것이다.
하지만 전제는 위에 적힌 내용을 이해하고 사용하는 것이다.
'잘 모르겠는데! 컴파일 오류가 없으니 OK'라는 심정으로 코드를 쓰면 위험하다(코딩 방법은 위험하다).세세히 생각해 보면 스위프트가 등장했을 때 닐 안전성은 패션으로 강조됐다.하지만 쉽게 사용!하면 nil 안전이 붕괴된다.그래서
쉽게 사용하기! 위험하다
그러나 ! 외관의 분위기도 영향을 미친다
사용! 위험
중요한 부분이 튀어나와 퍼졌을지도 모른다.
"이건 닐이 아니야", "여기에 오류가 있을 리가 없어", 잘 논의한 뒤 정확하게 사용!하는 것은 위험 신호가 아니라 전제조건을 나타내는 강력한 의사표시!4 이것은 나의 결론이다.
마지막으로'try 𐁆Swift'를 다시 한 번 보겠습니다.위험해요?아니야.
Swift가 실패하지 않겠다는 강력한 의지의 표시라고 생각합니다
금후그러니 위험한 사람을 봤을 때 이 기사를 알려주세요.
그리고,try!스위프트 연결니와타코의 깨우기.으로 표현하고 싶은 주제가 있지만, 이 작품이 잘 진행되고 있는지 모르겠다.  ↩
완전히 잡담이지만, 코틀린!에는'for NPE-lovers이라고 쓰여 있다.그러나 언어로서의 디자인 의도는 잘 이해되지 않는다.Java와 달리 NPE를 함부로 던지지 않습니다.NPE를 던질 때는 명시!!라고 하셨죠↩
!! 옵션으로 구축할 때 붕괴되지 않지만 어떤 동작이 일어날지 정의되지 않았습니다.  ↩
이것나의 강력한 의사표시↩