L'équipe Rust a accepté la proposition de la RFC 3355 il y a quelques mois et a décidé de commencer à développer une spécification officielle pour le langage Rust. Ce travail est dirigé par Eric (le responsable de Rust Reference), Felix (l'équipe linguistique Rust), Joel (la Fondation Rust) et Mara (l'auteur de la RFC).
À ce jour, quatre personnes d'Eric ont publié un document au nom de l'équipe de spécification pour présenter les derniers progrès de ce travail, ainsi que d'autres plans ultérieurs.
Éditeur
La première étape consiste à remplir le rôle « d'éditeur » spécifié dans la RFC . Les responsabilités de coordination et de rédaction de la spécification sont spécifiquement confiées à la Rust Foundation pour assurer la continuité des travaux.
Aucun candidat qualifié n’ayant été interviewé, la fondation a choisi d’envisager des options internes comme alternative. Dans le cadre de son travail actuel, Joël, directeur technique de la fondation, s'est montré ouvert aux candidatures pour le poste. Eric, Felix et Mara ont également accepté la proposition « en raison de sa vaste expérience dans les normes industrielles et l'édition technique, ainsi que de sa relation étroite avec le projet Rust ».
Équipe de spécification
Étant donné que le travail concerné ne peut pas être réalisé par un seul éditeur, une équipe est également constituée autour du travail de spécification, à savoir l'équipe de spécification, en tant que sous-équipe de l'équipe linguistique.
Les membres initiaux comprennent :
- Felix Klock (chef d'équipe)
- Mara Bos (chef d'équipe)
- Joel Marcey (membre de l'équipe, rédacteur)
- Eric Huss (membre de l'équipe)
Parties prenantes _ _ _
Une liste de parties prenantes sera sélectionnée et tenue à jour et servira de conseillers et d'examinateurs. La liste initiale comprend :
- Tous les membres de l'équipe linguistique Rust
- Un ou plusieurs représentants de l'équipe types
- un ou plusieurs représentants de l'équipe de sémantique opérationnelle
- Un ou plusieurs représentants de Ferrocene (haute fiabilité/disponibilité, par exemple industrie automobile.)
- Un ou plusieurs représentants de la Recherche et Développement de Méthodes Formelles
- Un ou plusieurs représentants du développement du système d'exploitation (Rust pour Linux ; Microsoft)
Autorité et approbation
Bien que l'équipe de spécification soit responsable de l'écriture et de l'édition de la spécification, la définition du langage Rust appartient toujours aux équipes concernées, telles que l'équipe linguistique et l'équipe API de la bibliothèque. Ces équipes doivent impliquer d'autres équipes/sous-équipes si nécessaire, par exemple en posant des questions, en nommant des sujets de discussion et en demandant l'approbation du FCP pour les décisions clés.
Pour permettre à l'équipe de spécifications de générer du contenu et d'itérer sans être contraint par un processus d'approbation, nous développerons des projets de spécifications dans un référentiel de travail. À l'aide de certains outils, nous suivrons publiquement quels projets nécessitent encore l'approbation de l'équipe et quels projets retiennent l'attention du public de la part des parties prenantes.
Nous classons tous les changements comme mineurs ou majeurs. Les changements mineurs sont des éléments qui ne semblent pas controversés ou insignifiants à l'équipe des spécifications. Par exemple, l'équipe linguistique a apporté des modifications approuvées par le FCP, des corrections typographiques et grammaticales, des clarifications d'intention et des modifications intéressantes similaires. Les changements significatifs sont ceux qui peuvent être problématiques, importants ou controversés. Tout membre de l’équipe de spécification et de l’équipe de l’autorité compétente, ainsi que toute partie prenante de la spécification, peut marquer un changement comme une rupture. Les modifications importantes apportées à la spécification doivent passer par le processus d'approbation habituel (tel que Language FCP) avant d'apparaître dans la version publiée (non brouillon) de la spécification.
Les équipes de langage et de spécification doivent s'efforcer d'avoir au moins un membre commun (par exemple Félix) qui sert de liaison pour garantir que notre compréhension des changements mineurs est en phase avec les changements majeurs.
Cible
L'objectif de l'équipe de spécification est de créer et de maintenir les spécifications Rust. Le but de la spécification Rust est de fournir une ressource faisant autorité pour déterminer quels textes sources sont des programmes Rust valides et comment ces programmes doivent se comporter.
Une spécification idéale nécessite à la fois :
- Définit les limites canoniques de la sémantique d'un programme Rust donné pour les versions actuelles et futures de Rust
- Fournit des détails décrivant la sémantique spécifique à la version Rust associée à cette instance de spécification.
Les dispositions relatives aux détails spécifiques à la version peuvent être fournies directement dans la spécification, ou indirectement par délégation à une autre documentation appartenant à l'équipe Rust concernée.
développement progressif
Il est nécessaire de fournir des contraintes normatives pour les versions actuelles et futures de Rust, mais aussi de décrire les détails de la version actuelle de Rust. L’équipe a donc décidé de maximiser la valeur de son travail grâce à une approche itérative et progressive.
Nous prévoyons que les premières versions de la spécification se concentreront sur la fourniture de descriptions détaillées des versions actuelles de Rust. Une telle spécification pourrait être dérivée de travaux existants tels que la spécification Ferrocene, puisque la spécification se concentre explicitement sur la fourniture d'instructions détaillées pour une version spécifique de Rust. Les commentaires sur ces descriptions spécifiques à la version nous aideront à comprendre la meilleure façon de formuler les contraintes normatives dans la spécification.
En raison des préoccupations que nous avons mentionnées plus tôt concernant les versions actuelles de Rust, les versions antérieures de la spécification pouvaient présenter des lacunes dans lesquelles les limites indiquées étaient moins précises que nécessaire. Par exemple, déclarer que « un code Rust dangereux peut conduire à un comportement non défini » ne fournit aucune indication sur la façon d'écrire un code dangereux bien défini. Même avec cette imprécision, les limites indiquées peuvent toujours fournir des garanties utiles de haut niveau (telles que « la sécurité de Rust ne conduit pas à un comportement indéfini »). Les futures versions de la spécification ajouteront des détails plus prescriptifs (par exemple « Le code Rust non sécurisé ne provoque pas de comportement indéfini dans les conditions suivantes : ») jusqu'à ce que nous atteignions le niveau de précision requis.
portée
La spécification doit couvrir au moins les domaines suivants de la syntaxe et de la sémantique de Rust. Certaines parties peuvent être intrinsèquement liées à des backends spécifiques ou à des technologies d'implémentation cibles (telles que l'asm en ligne).
- La syntaxe de Rust est spécifiée via Backus-Naur Form (BNF) ou une extension judicieuse de BNF.
- Extension des macros
- Transcription macro-par-exemple (
macro_rules); Hygiène cfgLes attributs- Macros procédurales ; attributs 以及 dériver
- Transcription macro-par-exemple (
- Résolution du chemin et de l'identifiant
- Modules
- sémantique statique
- définition de type ; expression de type ; mise en page
- Inférence de type et vérification de type ; sous-typage
- Vérifications du cycle de vie et des emprunts
- Génériques ; résolution d’associations et résolution de traits
- Sémantique opérationnelle de Safe Rust
- Tableaux de liaison ; expressions correspondantes ; déposer de la colle
- Déplacement et copie de valeurs ; emprunt
- projection sur le terrain ; répartition des méthodes
- surcharge de l'opérateur
- Sémantique opérationnelle Rust non sécurisée
- modèle de mémoire
- assemblage en ligne
- Évaluation constante
- Caisses et liaison de caisse
Cette liste peut être élargie au fil du temps.
Présentation
La spécification Rust sera un document accessible au public, similaire à tous les autres documents Rust (et aura les mêmes termes de licence ). Le texte sera rédigé en anglais et utilisera uniquement des termes techniques définis dans le cahier des charges lui-même ou avec des définitions claires dans des dictionnaires en ligne gratuits.
Les éléments individuels de la spécification peuvent être référencés et nommés : non seulement dans des hyperliens, mais également dans le texte (par exemple "[syntax.patterns.arm.5]"). Dans la mesure du possible, ces noms/références de projet doivent persister dans les différentes versions de la spécification.
Les itérations de la spécification doivent inclure des rendus mettant en évidence les différences entre les versions. (Voir le manuel de référence Ada, etc.)
La spécification Rust sera maintenue dans un format qui encourage les contributions bénévoles, même si l'équipe de spécification prévoit que chaque contribution doit être réautorisée pour maintenir la cohérence des spécifications.
Bien que l'exhaustivité et l'exactitude soient des priorités absolues, l'équipe s'efforcera de rendre les spécifications aussi compréhensibles que possible. Idéalement, tout programmeur Rust devrait être capable de creuser et de trouver des réponses à toutes ses questions linguistiques sans avoir à faire appel à un « avocat spécialisé en langage » qui connaît déjà intimement la documentation.
cadence de sortie
Les versions Rust se produiront indépendamment du processus d’approbation des spécifications.
Si la spécification d'une version donnée n'a pas encore été approuvée, cette version sera publiée sans spécification associée. (Cependant, l'équipe peut fournir ultérieurement des spécifications pertinentes pour une version donnée.)
C'est par conception. Le travail de spécification ne doit pas ajouter de nouveaux obstacles que le projet devra surmonter afin de respecter ses obligations existantes, comme un cycle de publication de 6 semaines.
La vision de l'équipe est d'arriver à terme au point où les spécifications mises à jour pourront être livrées automatiquement et conformément à la cadence de publication de 6 semaines du projet. Cependant, à court et moyen terme, il espère être libre de prendre du retard sur la cadence de sortie de 6 semaines. La possibilité d'être en retard sur le calendrier de publication de Rust peut être particulièrement utile lorsque l'équipe de spécification ajoute progressivement du nouveau contenu à des domaines non couverts auparavant, ou réduit considérablement la portée de la spécification pour la version actuelle de la spécification.
Bien que le processus de développement des spécifications n'empêche pas les versions, les modifications apportées aux fonctionnalités du langage doivent être associées à des mises à jour pertinentes de la spécification. Une fois que la publication d'une spécification associée à une version spécifique commence, les modifications apportées aux fonctionnalités linguistiques documentées dans la spécification actuelle ne peuvent pas être stabilisées sans que l'équipe de spécification n'approuve une demande d'extraction correspondante pour le projet de spécification actuel. Les modifications apportées aux fonctionnalités linguistiques qui ne sont pas documentées dans la spécification peuvent être stabilisées sans mettre à jour la spécification, mais nécessitent la confirmation d'un membre de l'équipe de spécification que la fonctionnalité correspondante n'est pas documentée.
En appliquant la règle selon laquelle les nouvelles fonctionnalités doivent faire partie de la spécification avant d'être stables, cela éliminera, espérons-le, une source majeure de décalage potentiel entre les spécifications et les versions de Rust.
L'étape suivante
- Créez un calendrier de réunions régulier pour l’équipe.
- Identifiez la liste des parties prenantes.
- Produire le premier « produit de démonstration » pour examen par les parties prenantes.