Pourquoi, dans presque tous les langages de programmation modernes (Go, Rust, Kotlin, Swift, Scala, Nim et même dernière version de Python), les types viennent toujours après le nom de la variable dans la déclaration de la variable et pas avant?

Pourquoi x: int = 42et pas int x = 42?
Ce dernier n'est-il pas plus lisible que l'ancien?
Est-ce juste une tendance ou y a-t-il des raisons vraiment significatives derrière cette solution?

Toutes les langues que vous avez mentionnées prennent en charge l' inférence de type , ce qui signifie que le type est une partie facultative de la déclaration dans ces langues, car elles sont assez intelligentes pour le remplir elles-mêmes lorsque vous fournissez une expression d'initialisation ayant un type facilement déterminé.

Cela est important, car placer les parties facultatives d'une expression plus à droite réduit l'analyse d'ambiguïté et augmente la cohérence entre les expressions qui utilisent cette partie et celles qui ne le font pas. Il est simplement plus simple d'analyser une déclaration lorsque vous connaissez le varmot - clé et le nom de la variable sont obligatoires avant de passer aux éléments facultatifs. En théorie, toutes les choses qui facilitent l'analyse des ordinateurs devraient également améliorer la lisibilité pour les humains, mais c'est beaucoup plus discutable.

Cet argument se particulièrement fort lorsque l' on considère tous les modificateurs de type option qu'une langue « non-moderne » comme C ++ a, comme *pour les pointeurs, &les références, const, volatileet ainsi de suite. Une fois que vous insérez des virgules pour plusieurs déclarations, vous commencez à avoir des ambiguïtés vraiment étranges, comme int* a, b;ne pas faire de bpointeur.

Même le C ++ supporte maintenant les déclarations "dactylographiées à droite" sous la forme de auto x = int{ 4 };, et il présente certains avantages .

Pourquoi dans presque tous les langages de programmation modernes (Go, Rust, Kotlin, Swift, Scala, Nim et même dernière version de Python), les types viennent toujours après la déclaration de variable, et pas avant?

Votre prémisse est défectueuse sur deux fronts:

• Il existe de nouveaux langages de programmation qui ont le type avant l'identifiant. C♯, D ou Ceylan, par exemple.
• Le type après l’identifiant n’est pas un phénomène nouveau, il remonte au moins à Pascal (conçu de 1968 à 1969, publié en 1970), mais a en fait été utilisé dans la théorie des types mathématiques, qui débute vers 1902. Il a également été utilisé dans ML (1973), CLU (1974), Hope (1970), Modula-2 (1977-1985), Ada (1980), Miranda (1985), Caml (1985), Eiffel (1985), Oberon (1986), Modula-3 (1986-1988) et Haskell (1989).

Pascal, ML, CLU, Modula-2 et Miranda étaient tous des langages très influents. Il n’est donc pas étonnant que ce style de déclaration de caractères soit resté populaire.

Pourquoi x: int = 42et pas int x = 42? Ce dernier n'est-il pas plus lisible que l'ancien?

La lisibilité est une question de familiarité. Personnellement, je trouve le chinois illisible, mais apparemment pas les Chinois. Avoir appris Pascal à l'école, côtoyé Eiffel, F♯, Haskell et Scala, et avoir regardé TypeScript, Fortress, Go, Rust, Kotlin, Idris, Frege, Agda, ML, Ocaml,…, cela me paraissait tout à fait naturel .

Est-ce juste une tendance ou y a-t-il des raisons vraiment significatives derrière une telle solution?

Si c'est une tendance, c'est assez persistant: comme je l'ai mentionné, cela remonte à cent ans en mathématiques.

L'un des principaux avantages d'avoir le type après l'identificateur est qu'il est facile de laisser le type en dehors si vous souhaitez l'inférer. Si vos déclarations ressemblent à ceci:

val i: Int = 10

Ensuite, il est trivial de laisser le type et de l'inférer comme ceci:

val i = 10

Considérant que si le type précède l'identifiant comme ceci:

Int i = 10

Ensuite, l'analyseur commence à avoir du mal à distinguer une expression d'une déclaration:

i = 10

La solution généralement proposée par les concepteurs de langage consiste à introduire un mot clé "je ne veux pas écrire de type" qui doit être écrit à la place du type:

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

Mais cela n'a pas vraiment de sens: vous devez fondamentalement écrire explicitement un type qui dit que vous n'écrivez pas de type. Hein? Il serait beaucoup plus facile et plus judicieux de simplement laisser tomber, mais cela rend la grammaire beaucoup plus complexe.

(Et ne parlons même pas des types de pointeurs de fonction en C.)

Les concepteurs de plusieurs des langues susmentionnées ont pesé à ce sujet:

• Go FAQ (voir aussi: Syntaxe de la déclaration de Go ):

  Pourquoi les déclarations sont-elles à l'envers?

  Ils sont seulement à l'envers si vous êtes habitué à C. En C, la notion est qu'une variable est déclarée comme une expression désignant son type, ce qui est une bonne idée, mais les grammaires de type et d'expression ne se mélangent pas très bien et les résultats peuvent être déroutants; considérez les pointeurs de fonction. Go sépare principalement l'expression et la syntaxe de type et cela simplifie les choses (l'utilisation du préfixe *pour les pointeurs est une exception qui prouve la règle). En C, la déclaration

  int* a, b;
  

  déclare aêtre un pointeur mais pas b; dans Go

  var a, b *int
  

  déclare que les deux sont des pointeurs. C'est plus clair et plus régulier. En outre, la :=forme courte déclaration soutient qu'une déclaration variable complète devrait présenter le même ordre que :=si

  var a uint64 = 1
  

  a le même effet que

  a := uint64(1)
  

  L'analyse syntaxique est également simplifiée par une grammaire distincte pour les types qui n'est pas simplement la grammaire d'expression; mots-clés tels que funcet changarder les choses claires.

• FAQ Kotlin :

  Pourquoi avoir des déclarations de type à droite?

  Nous pensons que cela rend le code plus lisible. En outre, il permet quelques fonctionnalités syntaxiques intéressantes. Par exemple, il est facile d’omettre les annotations de type. Scala a également prouvé que ce n’est pas un problème.

• Programmation en Scala :

  L’écart majeur par rapport à Java concerne la syntaxe des annotations de type - c’est " variable: Type" au lieu de " Type variable" en Java. La syntaxe de type postfixe de Scala ressemble à Pascal, Modula-2 ou Eiffel. La principale raison de cet écart est liée à l'inférence de type, qui vous permet souvent d'omettre le type d'une variable ou le type de retour d'une méthode. variable: TypeIl est facile d’ utiliser la syntaxe " " - il suffit d’omettre le côlon et le type. Mais dans la Type variablesyntaxe " " de style C, vous ne pouvez pas simplement laisser le type, il n’y aurait plus de marqueur pour commencer la définition. Vous auriez besoin d'un mot-clé alternatif comme espace réservé pour un type manquant (C♯ 3.0, qui effectue une inférence de type, utilise varà cette fin). Un tel mot clé alternatif semble plus ponctuel et moins régulier que l'approche de Scala.

Remarque: les concepteurs de Ceylan ont également expliqué pourquoi ils utilisaient la syntaxe de type préfixe :

Préfixe au lieu d'annotations de type postfix

Pourquoi suivez-vous C et Java pour placer les annotations de type en premier lieu, au lieu de Pascal et ML pour les placer après le nom de la déclaration?

Parce que nous pensons ceci:

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

Est tout simplement beaucoup plus facile à lire que cela:

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

Et nous ne comprenons tout simplement pas comment quiconque pourrait penser autrement!

Personnellement, je trouve leur "argument" beaucoup moins convaincant que les autres.

Pascal le fait aussi, d'ailleurs, et n'est pas un nouveau langage. C'était un langage académique cependant, conçu à partir de zéro.

Je dirais qu'il est sémantiquement plus clair de commencer par le nom de la variable. Le type est juste un détail technique. Si vous voulez lire votre classe comme un modèle de réalité, il est logique de mettre en premier le nom de vos entités et leur mise en œuvre technique.

C # et java étant issus de C, ils ont donc dû respecter "l'état de la technique" afin de ne pas confondre le programmeur expérimenté.

Pourquoi x: int = 42et pas int x = 42? Ce dernier n'est-il pas plus lisible que l'ancien?

Dans un exemple aussi simple, il n'y a pas beaucoup de différence, mais rendons-le un peu plus complexe: int* a, b;

C'est une déclaration valide en C, mais elle ne fait pas ce à quoi elle ressemble intuitivement. On dirait que nous déclarons deux variables de type int*, mais en réalité nous en déclarons une int*et une int.

Si votre langue place le type après le nom de la variable dans ses déclarations, le problème est impossible à résoudre.