Condition

Nous travaillons dur sur Go 1.13, dont la sortie, je l'espère, aura lieu début août de cette année. Il s'agit de la première version qui inclura des changements spécifiquement dans la langue (et pas seulement des changements mineurs à la spécification) après un long moratoire sur de tels changements.

Pour arriver à ces changements dans la langue, nous avons commencé avec plusieurs propositions viables, sélectionnées à partir d'une liste beaucoup plus grande d'offres Go 2 , conformément au nouveau processus d'évaluation des propositions décrit dans la publication « Go 2, nous voici !». Nous voulions que la sélection initiale de propositions par nous joue un rôle relativement restreint et, pour la plupart, ne provoque pas de controverse, de sorte qu'avec une forte probabilité, elles passeraient par tout le processus. Les modifications proposées devaient être rétrocompatibles afin de rompre le moins possible, car les modules (qui à l'avenir vous permettront de sélectionner la version linguistique d'un module particulier) ne sont pas encore le mode de construction par défaut. En bref, la phase initiale actuelle des changements visait davantage à décoller et à acquérir de l'expérience plutôt qu'à résoudre de gros problèmes.

Notre liste initiale de phrases - Unicode sous forme générale dans les identificateurs , les littéraux entiers binaires , les délimiteurs pour les littéraux numériques , les décalages de bits par un entier signé - a été raccourcie et étendue. La proposition d'Unicode en termes généraux d'identifiants n'a pas survécu à la réduction, car nous n'avons pas réussi à rédiger un document de conception à temps. La proposition de littéraux entiers binaires a été considérablement élargie et a conduit à un examen complet et à une modernisation de la syntaxe des littéraux numériques Go. Nous avons également ajouté un projet de proposition de vérification d'erreur Go 2, qui a été partiellement accepté.

Compte tenu de ces changements initiaux à Go 1.13, il est temps de penser à l'avenir de Go 1.14 et de déterminer ce que nous voulons changer ensuite.

Suggestions pour Go 1.14

Les objectifs que nous nous sommes fixés pour Go aujourd'hui sont les mêmes qu'en 2007: rendre le développement logiciel évolutif . Les trois principaux obstacles à l'amélioration de l'évolutivité de Go sont l'absence d'un système de gestion des packages et des versions, la prise en charge d'un meilleur système de gestion des erreurs et les génériques.

Avec l'amélioration du système de modules Go, le problème de la gestion des packages et des versions est en cours de résolution. Reste une gestion améliorée des erreurs et des génériques. Nous avons travaillé sur les deux questions et présenté des ébauches de documents de conception lors du GopherCon de l'an dernier à Denver. Depuis lors, nous les avons progressivement améliorés. Concernant le traitement des erreurs, nous avons publié une proposition considérablement révisée et simplifiée (voir ci-dessous). En ce qui concerne les génériques, nous y travaillons. «Generics in Go» de Ian Lance Taylor prononcera un discours sur ce sujet au GopherCon de San Diego cette année, mais nous n'avons pas encore atteint le stade où nous pourrions faire une proposition concrète.

Nous voulons également continuer à améliorer progressivement la langue elle-même. Pour Go 1.14, nous avons sélectionné les offres suivantes:

# 32437 . La fonction intégrée de vérification des erreurs est "try" ( document de conception ).

C'est notre suggestion pour améliorer la gestion des erreurs. Bien que l'extension linguistique proposée pour la compatibilité descendante soit petite, nous nous attendons à un impact significatif sur le code de gestion des erreurs. Cette proposition a déjà suscité un grand nombre de commentaires, et ce n'est pas si facile à suivre. Nous vous recommandons de commencer par le premier commentaire pour une brève description, puis de lire le document de conception détaillée. Le premier commentaire contient quelques liens vers un résumé des critiques. Veuillez suivre les directives de rétroaction (voir la section «Prochaines étapes») avant de répondre.

# 6977 . Autoriser l'intégration des interfaces qui se chevauchent ( document de conception ).

Il s'agit d'une ancienne proposition de compatibilité descendante pour rendre les interfaces d'intégration plus tolérantes.

# 32479 . Avertir de la conversion de la string(int) formulaire string(int) pour go vet .

Une conversion de la string(int) formulaire string(int) a longtemps été ajoutée à Go pour plus de commodité, mais elle est très déroutante pour les débutants (la string(10) est "\n" , pas "10" ) et n'est plus justifiée, car maintenant la conversion est disponible dans l' unicode/utf8 package unicode/utf8 . Étant donné que la suppression de cette transformation n'est pas une modification rétrocompatible, nous vous suggérons de lancer une erreur lors de la go vet .

# 32466 . Acceptez les principes de conception de la cryptographie ( document de conception ).

Il s'agit d'une demande de rétroaction pour un ensemble de principes de conception de bibliothèque cryptographique que nous aimerions accepter. Voir également la suggestion correspondante pour supprimer la prise en charge SSLv3 de crypto/tls .

Prochaines étapes

Nous recueillons activement des commentaires sur toutes ces suggestions. Nous sommes particulièrement intéressés par des preuves montrant pourquoi la proposition peut ne pas bien fonctionner dans la pratique, ou par des aspects problématiques que nous aurions pu manquer lors de l'élaboration. Des exemples convaincants à l'appui des suggestions sont également très utiles. En revanche, les commentaires ne contenant que des opinions personnelles sont moins efficaces: on peut les prendre en compte, mais on ne peut pas travailler de manière constructive avec eux. Avant de répondre, veuillez prendre un moment pour lire les documents de conception détaillés et les avis précédents ou leur résumé. Votre sujet a peut-être déjà été soulevé et discuté dans les commentaires précédents, en particulier lors de longues discussions.

Si ces propositions ne rencontrent pas de problèmes évidents, nous prévoyons de tout mettre en œuvre au début du cycle de développement Go 1.14 (début août 2019), afin que cela puisse déjà être évalué dans la pratique. Conformément au processus d'évaluation des propositions, la décision finale sera prise à la fin du cycle de développement (début novembre 2019).

Merci d'avoir aidé à améliorer la langue Go!

Robert Griesemer, pour l'équipe Go