Swift에 세미콜론이 필요하지 않은 이유는 무엇입니까? [닫은]


20

나는 일반적으로 c # 또는 Objective-C로 코딩하고 최근에 Apple의 새로운 프로그래밍 언어 인 Swift를 배우기 위해 그것을 취했습니다.

가장 먼저 눈에 띄는 것은 Swift에서 줄을 끝내기 위해 세미콜론을 추가 할 필요가 없지만 적어도 테스트 한 것에서 벗어나면 컴파일러를 방해하지 않는다는 것입니다.

내가 쓸 때 :

int someNumber = 0;

Objective-C에서 세미콜론은 프로그램에 줄이 끝나고 다음 줄로 넘어지지 않음을 알려줍니다.

Swift를 사용하면 변수를 선언 할 수 있습니다.

var someNumber:Int = 5

세미콜론을 추가하지 않으면 시스템은 이것이 줄의 끝이라는 것을 알고 있습니다.

어떤 언어는 이것을 할 수 있고 어떤 언어는 그렇지 않습니까? 세미콜론을 끝에 추가하는 균일 한 시스템을 유지해야하는 이유는 무엇입니까?


모든 사람들이 다른 언어에서 온 것은 아니기 때문에, 그들이 균일하지 않다는 것을 어떻게 알 수 있습니까? 애플은 많은 사람들이 싫어하는 Objective-C 부품을 제거하여 스위프트를 통해 더 많은 새로운 프로그래머를 끌어 들이지 않을까?
JeffO

2
많은 Obj-C 수의사는 Swift에 불만이 있으며 Obj-C를 선호합니다. 이것은 Apple 포럼을 통해 볼 수 있습니다. Swift는 2014 년에 나 왔으며 이번 가을에 Swift2.0이 출시되면서 몇 개월마다 한 달에 한 번씩 버그와 변경이 이루어졌습니다. Swift는 Obj-C를 기반으로하지만보다 평범한 영어로 코딩을보다 쉽게 ​​배울 수 있도록 만들어졌습니다.
Memj

구식 컴파일러 구현자는 단지 게 으르거나 더 간단한 구문 분석으로 더 효율적이어야했습니다. 더 이상 필요가 없습니다. 로컬 타입 추론과 동일합니다. 컴파일러 라이터가 게으르고 개발자 경험에 신경 쓰지 않는 경우에만 사용할 수 있습니다.
Ebuall

답변:


18

어떤 언어는 이것을 할 수 있고 어떤 언어는 그렇지 않습니까? 세미콜론을 끝에 추가하는 균일 한 시스템을 유지해야하는 이유는 무엇입니까?

Robert는 Swift에 대해 좋은 대답을했으며 일반적으로 구문 분석과 세미콜론을 사용하거나 사용하지 않는 이유에 대해 조금 더 추가하려고합니다.

프로그램을 컴파일 할 때 소스 파일을 실행 가능 코드로 변환하기 전에 몇 가지 단계가 있으며, 첫 번째는 읽기 및 구문 분석 중 하나입니다 . 구문 분석 중 코드는 언어 의 문법 에 따라 일련의 문자에서 구조화 된 표현으로 변환 됩니다. 이를 위해 코드를 구성하는 요소 (변수, 상수, 선언 등)를 식별하고 분리해야합니다. 다음과 같은 선언을 할 때 :

int someNumber = 0;

그것은 "어떤 someNumber유형 의 '것을 만들어서 int할당 0하는 것" 개념으로 돌아 가야하는 일련의 문자 뿐이다 .

이를 위해서는 명령문의 정확한 시작과 끝을 식별해야합니다. 당신이 이것을 가지고 있다고 상상해보십시오.

int someNumber = 0;
int otherNumber = 1;

그것들은 두 가지 다른 선언이라는 것을 알아야합니다. ;파서가이 일을 찾을 때까지 문자를 읽고, 시도 단지 하나의 문으로 읽은 것을 이해 할 수 있도록 C와 같은 언어가 사용됩니다있다. 이것은 Robert가 말했듯이 다음과 같이 같은 줄에 여러 문장을 가질 수 있습니다.

int someNumber = 0; int otherNumber = 1;

두 줄로 쓰는 것과 정확히 같은 효과가 있습니다.

Python 과 같은 다른 언어에서는 각 문장을 다른 줄에 배치해야합니다.

x = 3
if x < 10:
   print 'x smaller than 10'
else:
   print 'x is bigger than 10 or equal'

따라서 ;언어 자체로 인해 같은 줄에 문장을 추가 할 수 없으므로을 추가 할 필요가 없습니다 !

그러나 LISP 또는 Scheme 과 같은 다른 언어 는 문장을 그룹화하는 방법이 매우 다릅니다 (실제로 문장은 아니지만 지금은 무시합시다). 따라서 모든 것에 대한 괄호가 있습니다.

(define (do-stuff x)
  (begin
    (display (format "value: ~a" x))
    x))

다시 말하지만, 당신은 필요하지 않습니다 ;같은 문자 (사용하기 때문에 단지를 ), (것들에 대한) 다른 언어가에 있음을 {, }, :왜 필요합니까 : 만 리스프의 구문을 알고있는 등 누군가가 당신을 요청할 수 있습니다 ;명령문의 끝에서 ?

낯선 예를 추가하기 만하면됩니다 : OCaml 은 문장 끝에 세미콜론이있을뿐만 아니라 두 개가 있습니다!

let rec fact x =
    if x <= 1 then 1 else x * fact (x - 1);;

왜? 모르겠어요 :)

다른 언어는 다른 목적과 다른 철학으로 설계되었습니다. 모든 언어가 동일한 구문과 규칙을 공유하는 경우 동일한 방식으로 만 동일한 작업을 수행 할 수 있습니다.


4
좋은 종결 문장.
Thomas Eding

좋은 예이지만 질문에 대답하지 않았습니다.
Robo Robok

추가 데이터 포인트 : 일부 언어는 C 스타일 제품군에 일종의 역 접근 방식을 사용합니다. 예를 들어 HyperTalk는 세미콜론 대신 줄 바꿈으로 줄 바꿈을 사용하고 명령문을 계속하려면 줄 바꿈을 필요로합니다. 여러 줄에 걸쳐. 놀랍게도 C의 자체 전처리 기는 그런 식으로 작동합니다.
uliwitness

11

명령문 끝을 구분하기 위해 세미콜론 대신 줄 바꿈이 사용됩니다.

에서 언어 가이드 : 기본 은 말한다 :

다른 많은 언어와 달리 Swift에서는 코드에서 각 문장 뒤에 세미콜론 (;)을 쓰지 않아도되지만 원하는 경우 그렇게 할 수 있습니다. 그러나 한 줄에 여러 개의 개별 문을 쓰려면 세미콜론이 필요합니다.

왜? 그것이 언어 설계자가 원하는 방식이기 때문입니다.

위의 두 번째 문장은 세미콜론이 필요없는 이유를 암시합니다. 대부분의 진술은 한 줄입니다. 이 Bubble Sort 예제를 관찰하십시오. 세미콜론이없는 단일 행 명령문의 조합은 VB와 비슷하지만 덜 장황한 구문을 만듭니다.

func bubbleSort<T:Comparable>(inout list:[T]) {
    var done = false
    while !done {
        done = true
        for i in 1..<list.count {
            if list[i - 1] > list[i] {
                (list[i], list[i - 1]) = (list[i - 1], list[i])
                done = false
            }
        }
    }
}

Swift의 문장은 일반적으로 줄 바꿈으로 끝나기 때문에 문장의 끝을 표시 할 세미콜론의 필요성이 줄어 듭니다. 세미콜론을 사용하는 다른 언어는이 방식으로 작동하지 않습니다. 여러 줄로 된 문장을 자유롭게 작성할 수 있지만, 명령문이 끝났다는 것을 컴파일러가 알고있는 유일한 방법은 세미콜론을 그 끝에 놓는 것입니다.

명령문이 줄 바꿈으로 끝나지 않으면 Swift 컴파일러가 이전 줄의 연속으로 인식 할 수있는 위치에 줄 바꿈을 넣어야합니다.

let s2 = str
        .lowercaseString
        .replace("hello", withString: "goodbye")

2
마지막 문장은 거짓이며 줄 바꿈을 배치 할 특정 위치가 없습니다. 가독성을 높이기 위해 코드 줄을 들여 쓰고 정렬하는 것이 좋습니다.
Eneko Alonso

재미있는 사실 : 이것은 오류보고에 영향을 미칩니다. 많은 C 컴파일러 (clang이 특히 우수함)는 세미콜론을 사용하여 구문 오류가있는 명령문의 끝을 찾고 해당 정보를 사용하여 누락 된 닫는 괄호를 실제로 누락 된 위치에 더 가깝게보고합니다. 세미콜론이없고 Swift에서 오류가 발생하면 다음 행이 오류가있는 선행 작업으로 축소되어 실제로 이상한 오류 메시지가 발생할 수 있습니다.
uliwitness
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.