누구?

안녕하세요. FC 서비스 개발팀에서 육아(샤워 전문)와 iOS 앱(배민프레시) 개발을 담당하고 있는 최광훈입니다.

발단

배민프레시 2.0.0 iOS버전을 무사히 올리고, 아기 샤워를 마치고, 밥을 먹이고, 잠을 재우고(그러나 새벽에 다시 깨었지. 30분을 울었지.), 사랑하는 부인과 함께 이유식을 만든 후, 고요함이 찾아온 금요일 저녁이었습니다. 그 동안 뒤쳐진 사회성을 끌어올리기 위해 facebook을 정주행중이었는데, 타임라인에서 김범준 이사님의 포스팅 하나를 보게 되었습니다.

포스팅

stackoverflow의 글에 대한 포스팅이었는데 해당 내용인즉

var i = 0
for i in 0..<10 { ... }

외부 변수 i를 for in문의 index i로 사용해서 외부 변수를 변경하는 것이 불가능하지요? 라는 질문이었습니다. Swift의 문법에서는 스코프 바깥의 변수 혹은 상수명과 동일한 명칭을 스코프 안에서 사용한 경우 별개의 선언으로 취급하며, 동일한 명칭에 대한 shadowning 경고도 없기 때문에, 위와 같은 질문이 나오게 된 거죠.

포스팅에 몇가지 유사한 경우를 댓글로 달다 애초에 for item in collection { … }의 형태가 사용자에게 오해를 줄 여지가 있다면, 그리고 경고보다 좀 더 확실한 표현으로 제한이 가능하다면 어떨까 하는 생각이 들게 되었습니다.

스위프트 커뮤니티

Swift는 open source로 전환을 시작한 후부터 여러 형태로 사용자들이 기여할 수 있도록 하고 있습니다.

  • 기여의 방법

    • 질문하기
    • 버그보고하기
    • 코드 기여
    • 외부 라이브러리 dependency 추가
    • Swift Evolution에 참여하기
      • 바로 이 글에서 할 일입니다.

개발자들의 토론의 장도 필요하겠죠? swift.org에서는 다음과 같은 메일링 리스트를 통해 커뮤니티를 구성하고 있습니다.

  • 개발자 메일링리스트

    • 일반
      • swift-users : Swift의 일반 사용자들이 Swift와 관련하여 도움이나 질문을 받을 수 있는 메일링 리스트입니다.
    • 개발
      • swift-dev : 개발자들이 Swift의 컴파일러, 저수준 런타임, 표준 라이브러리, SourceKit(IDE support framework)의 구현에 대해 토론합니다.
      • swift-corelibs-dev - Swift 코어 라이브러리의 구현에 대해 토론합니다.
      • swift-server-dev - Server APIs work group에서 서버에 맞춰 개발한 부분의 구현에 대해 토론합니다.
      • swift-lldb-dev - Swift REPL과 LLDB의 Swift 특화의 구현에 대해 토론합니다.
      • swift-build-dev - Swift package manager와 low level build system (llbuild)에 대해 토론합니다.
    • Swift Evolution

자 그럼 이제 제안을 해볼까요?

제가 제안 할 내용은 다음과 같습니다.

for item in collection {}

를

for collection { (item) in }

로 제안하려고 합니다.

swift-evolution링크로 이동하겠습니다.

바로전의 깔끔한 화면과는 달리 좀 단촐해보이는 페이지가 등장합니다. 오픈 소스 커뮤니티의 메일링 리스트는 GNU 메일링 리스트 관리툴인 Mailman을 사용하는 경우가 많아 같은 형태의 레이아웃을 자주 볼 수 있습니다.

구성

  • 읽기 - swift-evolution Archives을 통해서 현재까지의 포스팅을 볼 수 있습니다.
  • 쓰기 - 메일링 리스트의 모든 구성원에게 메시지를 보내려면 swift-evolution@swift.org로 메일을 보내면 됩니다.
  • 구독하기 - 구독할 이메일과 암호등의 정보를 입력하고 Subscribe버튼을 클릭합니다.
  • 하단의 구독자 리스트 보기는 관리자만 사용가능합니다.
  • 구독 해지하기 - 이메일을 입력 후 간단히 해지 버튼을 클릭하면 해방입니다.

이제 메일을 보내면 archives에 바로 등록됩니다.

[swift-evolution] Change ‘for in’ expression to for [] { (item) in … } 의 내용으로 메일을 보냈습니다. 엉터리 영어로 쓴지라 두근두근했지만, 그냥 send를 눌렀습니다. (지금 다시 보니 제가 stackoverflow의 원글을 잘못 이해했다는 것도 알 수가 있네요.)

별 기대는 안하고 다른 일을 하고 있는데, 12분 지나고 첫 메시지가 도착했습니다. (내용은 요약한 버전입니다.)

Alex Blewitt : forEach 쓰시면 됩니다.

그리고 몇 개의 메시지가 추가로 도착했습니다.

Jacob Williams : 기존 문법을 대치하는 것은 너무 많은 양의 수정사항을 발생시키며, forEach 쓰면 됩니다.

Robert Bennett : forEach와 똑같은데요?

이대로 수긍하기에는 제 설명이 너무 부족했던지라 저도 부연설명을 추가했습니다.

저 : 0..<10과 같은 Range타입인 경우 forEach를 쓰려면 (0..<10).forEach { … }와 같은 괄호로 감쌀 필요가 있어요. 불편하니까 그냥 for in바꾸진 말구 새로 추가하면 어때요? 물론 이미 기존의 for문 하나 없에서 좀 더 깔끔한 코드를 만들게 해줬지만 말이에요. (Swift 2까지는 for in문 외에도, 일반적인 for문이 존재했었습니다.)

Robert Bennett : 이미 대체할 방법이 있는데다, 언어의 발전은 기본 문법의 결함을 감추는 것 이상이다.

  • 해석이 잘 안되는 제 기분을 반영해서 말투가 딱딱해졌습니다.

Haravikk : 의도에는 동감하나 잘못된 해결 방법인거 같습니다. 그보다 shadowning이 발생하는 상황을 제거하거나 경고를 추가하는 것이 어떨까요. 개인적으로는 변수명을 좀 더 고민하는게 좋겠습니다.

  • 변수명이 좀 더 의도를 드러내도록 해야한다는 것에 공감했습니다. 참고로 swiftlint의 convention rule에서는 변수나 상수의 명칭에 single character를 사용하지 않도록 권고합니다.

Taylor Swift : 사실 for문에서 외부 변수를 사용하는 것은 C가 심하게 비판받는 부분입니다. 이 변화는 더 심한 혼란을 야기할 것입니다.

  • 진짜 테일러 스위프트는 아닙니다.

이 시점에서 저는 모두의 견해에 고마음을 표하는 답변을 보냈습니다. 그리고 다음날 아침 즈음에 하나의 답변이 추가로 도착했습니다.

Daryle Walker : nested function을 없애고, 모든 지역 변수는 동일한 이름을 가져선 안되는 것이 좋을 거 같습니다. 이런 언어에 대해 읽은 적이 있네요.

마치며

Swift의 철학은 안전, 신속, 표현성으로 대표됩니다. 그리고 그를 위해서 Apple의 Swift 코어 개발자 뿐만 아니라 Swift를 사용하는 수많은 개발자들이 제안을 하고 토론을 하며 그 중에서 Swift 명세에 추가가 정해지며, 다시 검토를 통해 탈락 하기도 합니다. 또한 어마어마한 개발자들의 신적인 토론의 장이 아니라 저 같은 보통개발자들도 참여할 수 있는 열린 교류의 장이기도 합니다.

제가 제 부족한 제안에 대해 글을 쓴 것은 여러분도 겁내지 말고 Swift의 발전에 대해 재밌게 참여 할 수 있기를 바라기 때문입니다.

*마지막으로

세상에서 제일 짧은 제안이 얼마나 긴 thread가 되고 결국 Swift 3에 포함되었는지 보면 재미납니다. (나만 그런가…)

nulTerminatedUTF8의 nul이 오타라고 생각했던 세상에서 제일 짧은 제안이 Swift 3의 명세가 됩니다.

And Thanks Google Translate.