Чому так, що майже в усіх сучасних мовах програмування (Go, Rust, Kotlin, Swift, Scala, Nim, навіть остання версія Python) типи завжди приходять після імені змінної в декларації змінної, а не раніше?

Чому x: int = 42і ні int x = 42?
Чи останні не є більш читабельними, ніж перші?
Це просто тенденція чи є якісь справді значущі причини, що стоять за цим рішенням?

Усі мови, про які ви згадали, є висновками про тип підтримки , а це означає, що тип є необов'язковою частиною декларації на цих мовах, оскільки вони досить розумні, щоб заповнити їх у себе, коли ви надаєте вираз ініціалізації, який має легко визначити тип.

Це важливо, оскільки розміщення необов'язкових частин виразу далі праворуч зменшує розбір неоднозначності та збільшує узгодженість між виразами, які використовують цю частину, та тими, які не використовують. Простіше проаналізувати декларацію, коли ви знаєте, що varключове слово та ім’я змінної обоє є обов'язковими, перш ніж перейти до необов'язкового матеріалу. Теоретично, все те, що полегшує розбір для комп’ютерів, також повинно покращити загальну читанність для людей, але це набагато більш дискусійно.

Цей аргумент стає особливо сильним , коли ви враховуєте всі необов'язкові модифікатори типу , що не «сучасний» мову , як C ++ має, наприклад, *для покажчиків, &для посилань const, volatileі так далі. Як тільки ви кидаєте коми для декількох декларацій, ви починаєте отримувати деякі дійсно дивні неоднозначності, як int* a, b;не робити bпокажчик.

Навіть C ++ тепер підтримує декларації типу "праворуч" у формі auto x = int{ 4 };, і це має деякі переваги .

Чому майже у всіх сучасних мовах програмування (Go, Rust, Kotlin, Swift, Scala, Nim, навіть остання версія Python) типи завжди надходять після оголошення змінної, а не раніше?

Ваше приміщення є недоліком на двох фронтах:

• Існують нові мови програмування, які мають тип перед ідентифікатором. Наприклад, C♯, D або Цейлон.
• Наявність типу після ідентифікатора не є новим явищем, воно повертається принаймні до Паскаля (розроблений 1968-1969 рр., Випущений у 1970 р.), Але насправді використовувався в математичній теорії типів, яка починається з 1902 р. Він також використовувався в ML (1973), CLU (1974), Hope (1970), Modula-2 (1977–1985), Ada (1980), Міранда (1985), Caml (1985), Eiffel (1985), Oberon (1986), Модула-3 (1986–1988) та Хаскелл (1989).

Паскаль, ML, CLU, Modula-2 і Miranda всі були дуже впливовими мовами, тому не дивно, що цей стиль декларацій типу залишався популярним.

Чому x: int = 42і ні int x = 42? Чи останні не є більш читабельними, ніж перші?

Читання - це питання знайомства. Особисто я вважаю китайську мову нечитаючою, але, мабуть, китайці цього не роблять. Дізнавшись Паскаля в школі, посварившись з Ейфелем, F♯, Хаскеллом та Скалою, а також подивившись на TypeScript, Fortress, Go, Rust, Kotlin, Idris, Frege, Agda, ML, Ocaml,…, мені це здається абсолютно природним .

Це просто тенденція чи є якісь справді значущі причини, що стоять за таким рішенням?

Якщо це тенденція, вона досить наполеглива: як я вже згадував, це математика йде на сто років назад.

Однією з головних переваг наявності типу після ідентифікатора є те, що легко залишити тип, якщо ви хочете, щоб він міг зробити висновок. Якщо ваші декларації виглядають так:

val i: Int = 10

Тоді тривіально виключати тип і робити це таким чином:

val i = 10

Беручи до уваги, якщо тип стоїть перед таким ідентифікатором:

Int i = 10

Тоді аналізатору починає важко відрізняти вираз від декларації:

i = 10

Рішення, яке зазвичай розробляють мовні дизайнери, - це ввести ключове слово "Я не хочу писати тип", яке потрібно писати замість типу:

var  i = 10; // C♯
auto i = 10; // C++

Але це насправді не має великого сенсу: в основному ви повинні явно написати тип, який говорить про те, що ви не пишете тип. Так? Було б набагато простіше і розумніше просто залишити це, але це робить граматику набагато складнішою.

(І давайте навіть не говорити про типи вказівників функцій у C.)

Дизайнери кількох вищезгаданих мов зважили на цю тему:

• Перейти до поширених запитань (див. Також: Синтаксис декларації Go ):

  Чому декларації зворотні?

  Вони лише назад, якщо ви звикли до C. У C поняття полягає в тому, що змінна оголошується як вираз, що позначає її тип, що є приємною ідеєю, але граматики типу та виразів не дуже добре поєднуються, і результати можуть бути заплутаними; розглянемо функціональні покажчики. Переважно розділяє синтаксис виразів і типів, що спрощує речі (використання префікса *для покажчиків - виняток, що підтверджує правило). В С декларація

  int* a, b;
  

  оголошує aвказівником, але ні b; в Го

  var a, b *int
  

  оголошує обох покажчиками. Це чіткіше і регулярніше. Також :=форма короткої декларації стверджує, що повна заява змінної повинна представляти той самий порядок, що і :=так

  var a uint64 = 1
  

  має такий же ефект, як і

  a := uint64(1)
  

  Парсинг також спрощується, маючи чітку граматику для типів, які не є лише граматикою виразу; такі ключові слова, як funcі chanзабезпечують чіткість.

• Котлін FAQ :

  Чому праворуч декларації типу?

  Ми вважаємо, що це робить код читабельнішим. Крім того, це дає деякі приємні синтаксичні особливості. Наприклад, легко залишити анотації типу. Scala також досить добре зарекомендувала себе, це не проблема.

• Програмування в Scala :

  Основне відхилення від Java стосується синтаксису для анотацій типів - це " variable: Type" замість " Type variable" у Java. Синтаксис типу постфікса Scala нагадує Паскаль, Модулу-2 або Ейфель. Основна причина цього відхилення пов'язана з висновком типу, який часто дозволяє опускати тип змінної або тип повернення методу. Використовувати variable: Typeсинтаксис " " це легко - просто залиште двокрапку та тип. Але в Type variableсинтаксисі стилю C " " ви не можете просто залишити тип - маркер, який би починав визначення, більше не мав би. Вам знадобиться якесь альтернативне ключове слово, щоб бути заповнювачем для відсутнього типу (C♯ 3.0, який робить певний тип виводу, використовується varдля цієї мети). Таке альтернативне ключове слово вважається більш спеціальним та менш регулярним, ніж підхід Scala.

Примітка: дизайнери Цейлону також задокументували, чому вони використовують синтаксис типу префікса :

Префікс замість анотацій типу постфікса

Чому ви дотримуєтесь C та Java, коли в першу чергу викладаєте анотації типу, а не Pascal та ML, а їх після імені декларації?

Тому що ми думаємо так:

shared Float e = ....
shared Float log(Float b, Float x) { ... }

Просто читати набагато простіше, ніж це:

shared value e: Float = .... 
shared function log(b: Float, x: Float): Float { ... }

І ми просто не розуміємо, як хтось може подумати інакше!

Особисто я вважаю їх "аргумент" набагато менш переконливим, ніж інші.

Паскаль робить це теж до речі, і це не нова мова. Це була академічна мова, але розроблена з нуля.

Я б сказав, що семантично зрозуміліше починати з назви змінної. Тип - це лише технічна деталь. Якщо ви хочете прочитати свій клас на зразок такої моделі реальності, має сенс спочатку поставити назви ваших організацій та їх технічну реалізацію.

C # і java походять від C, тому їм довелося поважати "попередній рівень техніки", щоб не плутати досвідченого програміста.

Чому x: int = 42і ні int x = 42? Чи останні не є більш читабельними, ніж перші?

У такому простому прикладі різниці немає, але давайте зробимо це трохи складніше: int* a, b;

Це дійсна, дійсна декларація в C, але вона не робить те, що інтуїтивно виглядає так, як це повинно робити. Схоже, ми оголошуємо дві змінні типу int*, але насправді ми оголошуємо одну int*та одну int.

Якщо ваша мова в своїх деклараціях вводить тип після імені змінної, цієї проблеми неможливо зіткнутися.