Почему Голанг принуждает фигурные скобки, чтобы их не было на следующей строке?

Ответ 1

Почему есть скобки, но нет точек с запятой? И почему я не могу положить открытую фигуру на следующей строке?

Go использует скобки для группировки операторов, синтаксис, знакомый программистам, которые работали с любым языком семейства C. Точки с запятой, однако, предназначены для парсеров, а не для людей, и мы хотели как можно больше их устранить. Для достижения этой цели Go заимствует трюк из BCPL: точки с запятой, которые разделяют утверждения, находятся в формальной грамматике, но вводятся автоматически, без видимости, лексером в конце любой строки, которая может быть завершением инструкции. Это очень хорошо работает на практике, но имеет эффект, что он создает стиль фигурной скобки. Например, открывающая фигурная скобка функции не может отображаться на отдельной строке.

http://golang.org/doc/faq#semicolons

Ответ 2

В большинстве языков C используется стиль if ( <condition> ) <statement>, statement выполняется, если condition - true. statement может быть либо отдельным оператором, либо закрытым блоком.

Go if требуют следующего блока, заключенного в фигурные скобки, а не одного оператора. Это должно означать общую ошибку, которую большинство руководств по стилям пытаются избежать, требуя, чтобы все операторы if использовали фигурные скобки.

//subtle error in C
if (<condition>)
  <statement1>;
  <statement2>;

Теперь, когда Go требует блок скобок, следующий за оператором if, () являются избыточными. Они служат только для того, чтобы помочь лексеру различать условие и утверждение, иначе if <condition> <statement> трудно разобрать. (Где заканчивается условие и утверждение?)

Теперь у авторов есть решение сделать:

• Сохраняйте избыточность ()
• требуется { следовать <condition>

Они решили, что избыточность нежелательна. Это имело второй побочный эффект. Поскольку в каждой новой строке есть неявный ;, если { находится в следующей строке, a ; устанавливается между <condition> и {. Идут авторы снова сталкиваются с решением:

• специальный случай, чтобы анализатор был умным относительно конструкции <condition>; {
• требуется, чтобы каждый принимал общий стиль if ... { в той же строке.
• требуют, чтобы <condition> находился в одной строке.

Специальный корпус анализатора - очень плохая вещь. Посмотрите на скорость D и сравните синтаксические анализаторы по сравнению с сильным синтаксическим анализом С++. И одинаковый стиль - это хорошо. Их окончательное решение довольно просто с учетом ограничений.

Ответ 3

Я думаю, что эта брекет-форсирующая вещь - просто повод сделать людей, которые любят стиль K & R, чтобы не видеть стиль Allman. Если бы дизайнеру (-ам) понравился стиль Allman, то он или она просто заставил бы парсер справиться с этим. Представьте, что XML был написан в K & R. Понять было бы невозможно. Стиль Allman намного проще и быстрее читать. Кажется, это совершенно эмоциональное решение. Я тоже сделаю: игнорировать Go.

Ответ 4

Это связано с Spec, то есть не только что-то, что они встроили в свои компиляторы

запятой

Формальная грамматика использует точки с запятой ";" как терминаторы в ряде производства. Программы Go могут пропускать большую часть этих точек с запятой, используя следуя двум правилам:

Когда вход разбит на токены, точка с запятой автоматически вставляется в поток токенов в конце непустой строки, если конечный токен линии

• идентификатор
• целочисленный, плавающий, мнимый, рунический или строковый литерал
• одно из ключевых слов break, continue, fallthrough или return
• один из операторов и разделителей ++, -,),] или}

Чтобы позволить сложным операторам занимать одну строку, точка с запятой может быть опущена до закрытия ")" или "}".

Чтобы отразить идиоматическое использование, примеры кода в этом документе elide точки с запятой, используя эти правила.

Насколько я понял это из своих разговоров, они хотели избавиться от форматирования-обсуждения и расширили идею с помощью grea gofmt