Por que quase todos os tipos de linguagens de programação modernas (Go, Rust, Kotlin, Swift, Scala, Nim e até Python) sempre vêm após o nome da variável na declaração da variável, e não antes?

Por que x: int = 42e não int x = 42?
O último não é mais legível que o primeiro?
É apenas uma tendência ou existem razões realmente significativas por trás dessa solução?

Todos os idiomas que você mencionou suportam inferência de tipo , o que significa que o tipo é uma parte opcional da declaração nesses idiomas, porque são inteligentes o suficiente para preenchê-los quando você fornece uma expressão de inicialização que tem um tipo facilmente determinado.

Isso importa porque colocar as partes opcionais de uma expressão mais à direita reduz a ambiguidade da análise e aumenta a consistência entre as expressões que usam essa parte e as que não o fazem. É mais simples analisar uma declaração quando você sabe que a varpalavra - chave e o nome da variável são obrigatórios antes de acessar o material opcional. Em teoria, todas as coisas que facilitam a análise de computadores também devem melhorar a legibilidade geral para os seres humanos, mas isso é muito mais discutível.

Este argumento fica especialmente forte quando se consideram todos os modificadores opcionais tipo que uma língua "não-moderno", como C ++ tem, como *para ponteiros, &para referências, const, volatilee assim por diante. Depois de inserir vírgulas para várias declarações, você começa a obter algumas ambiguidades realmente estranhas, como int* a, b;não fazer bum ponteiro.

Até o C ++ agora suporta declarações "digite à direita" na forma de auto x = int{ 4 };, e possui algumas vantagens .

Por que em quase todas as linguagens de programação modernas (Go, Rust, Kotlin, Swift, Scala, Nim e até a última versão do Python) os tipos sempre vêm após a declaração da variável, e não antes?

Sua premissa é falha em duas frentes:

• Existem novas linguagens de programação que têm o tipo antes do identificador. C♯, D ou Ceilão, por exemplo.
• Tendo o tipo após o identificador não é um fenômeno novo, ele remonta a pelo menos Pascal (projetado 1968-1969, lançado em 1970), mas na verdade foi usado na teoria matemática dos tipos, que começa em 1902. Também foi usado em ML (1973), CLU (1974), Hope (1970), Modula-2 (1977-1985), Ada (1980), Miranda (1985), Caml (1985), Eiffel (1985), Oberon (1986), Modula-3 (1986-1988) e Haskell (1989).

Pascal, ML, CLU, Modula-2 e Miranda eram linguagens muito influentes; portanto, não é de surpreender que esse estilo de declaração de tipo permanecesse popular.

Por que x: int = 42e não int x = 42? O último não é mais legível que o primeiro?

A legibilidade é uma questão de familiaridade. Pessoalmente, acho o chinês ilegível, mas aparentemente o povo chinês não. Tendo aprendido Pascal na escola, brincado com Eiffel, F♯, Haskell e Scala, e tendo olhado para TypeScript, Fortress, Go, Rust, Kotlin, Idris, Frege, Agda, ML, Ocaml,…, parece completamente natural para mim .

É apenas uma tendência ou existem razões realmente significativas por trás dessa solução?

Se é uma tendência, é bastante persistente: como mencionei, remonta a cem anos em matemática.

Uma das principais vantagens de ter o tipo após o identificador é que é fácil deixar o tipo de fora, se você desejar que ele seja deduzido. Se suas declarações forem assim:

val i: Int = 10

Então é trivial deixar de fora o tipo e inferi-lo assim:

val i = 10

Considerando que, se o tipo vier antes do identificador, desta forma:

Int i = 10

Então, fica difícil para o analisador distinguir uma expressão de uma declaração:

i = 10

A solução que os designers de linguagem geralmente apresentam é a introdução de uma palavra-chave "Não quero escrever um tipo" que deve ser escrita em vez do tipo:

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

Mas isso realmente não faz muito sentido: você basicamente precisa escrever explicitamente um tipo que diz que você não escreve um tipo. Hã? Seria muito mais fácil e sensato deixar de fora, mas isso torna a gramática muito mais complexa.

(E não vamos nem falar sobre os tipos de ponteiros de função em C.)

Os projetistas de várias das línguas mencionadas anteriormente abordaram esse assunto:

• Go FAQ (consulte também: Sintaxe da declaração de Go ):

  Por que as declarações são invertidas?

  Eles estão apenas ao contrário se você estiver acostumado a C. Em C, a noção é que uma variável é declarada como uma expressão que indica seu tipo, o que é uma boa ideia, mas as gramáticas de tipo e expressão não se misturam muito bem e os resultados podem ser confusos; considere ponteiros de função. Go principalmente separa a expressão e o tipo de sintaxe e isso simplifica as coisas (o uso do prefixo *para ponteiros é uma exceção que comprova a regra). Em C, a declaração

  int* a, b;
  

  declara aser um ponteiro, mas não b; em Go

  var a, b *int
  

  declara que ambos são ponteiros. Isso é mais claro e mais regular. Além disso, o :=formulário de declaração abreviada argumenta que uma declaração variável completa deve apresentar a mesma ordem que :=a

  var a uint64 = 1
  

  tem o mesmo efeito que

  a := uint64(1)
  

  A análise também é simplificada por ter uma gramática distinta para tipos que não é apenas a gramática da expressão; palavras-chave como funce chanmantenha as coisas claras.

• Perguntas frequentes sobre o Kotlin :

  Por que ter declarações de tipo à direita?

  Acreditamos que torna o código mais legível. Além disso, ele permite alguns recursos sintáticos agradáveis. Por exemplo, é fácil deixar anotações de tipo. Scala também provou muito bem que isso não é um problema.

• Programação em Scala :

  O principal desvio do Java diz respeito à sintaxe das anotações de tipo - é " variable: Type" em vez de " Type variable" em Java. A sintaxe do tipo postfix de Scala se assemelha a Pascal, Modula-2 ou Eiffel. O principal motivo desse desvio está relacionado à inferência de tipo, que geralmente permite omitir o tipo de uma variável ou o tipo de retorno de um método. Usar a variable: Typesintaxe " " é fácil - deixe de fora os dois pontos e o tipo. Mas na Type variablesintaxe " " do estilo C, você não pode simplesmente deixar de fora o tipo - não haveria mais marcador para iniciar a definição. Você precisaria de alguma palavra-chave alternativa para ser um espaço reservado para um tipo ausente (o C♯ 3.0, que faz alguma inferência de tipo, usa varpara esse fim). Essa palavra-chave alternativa parece mais ad-hoc e menos regular do que a abordagem da Scala.

Nota: os designers do Ceilão também documentaram por que usam a sintaxe do tipo de prefixo :

Prefixo em vez de anotações do tipo postfix

Por que você segue C e Java colocando as anotações de tipo primeiro, em vez de Pascal e ML colocando-as após o nome da declaração?

Porque pensamos isso:

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

É simplesmente muito mais fácil de ler do que isso:

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

E simplesmente não entendemos como alguém poderia pensar o contrário!

Pessoalmente, acho o "argumento" deles muito menos convincente do que os outros.

Pascal faz isso também por sinal, e não é um novo idioma. Era uma linguagem acadêmica, projetada do zero.

Eu diria que é semanticamente mais claro começar com o nome da variável. O tipo é apenas um detalhe técnico. Se você quiser ler sua classe como o modelo de realidade atual, faz sentido colocar os nomes de suas entidades em primeiro lugar e sua implementação técnica por último.

C # e java derivam de C, então eles tiveram que respeitar a "arte anterior", para não confundir o programador experiente.

Por que x: int = 42e não int x = 42? O último não é mais legível que o primeiro?

Em um exemplo tão simples, não há muita diferença, mas vamos torná-lo um pouco mais complexo: int* a, b;

Esta é uma declaração válida e real em C, mas não faz o que parece intuitivamente que deveria fazer. Parece que estamos declarando duas variáveis ​​do tipo int*, mas na verdade estamos declarando uma int*e uma int.

Se o seu idioma colocar o tipo após o (s) nome (s) da variável em suas declarações, é impossível encontrar esse problema.