Nouvelle syntaxe pour l'introduction de async/await dans Rust
Date:
[]
Catégories:
[Technique]
Tags:
[Rust]
Rust
Je n’ai pas encore décrit Rust sur mon blog. Rust est un langage de programmation (non je ne parlerais jamais du jeu du même nom.) qui vise à fournir un écosystème et des fonctionnalitées qu’on rencontre fréquement dans les langages de haut niveau. Ça c’est si on vient de langages de bas niveau. Si on vient des langages de script/haut niveau, Rust vise à offrir la vitesse d’exécution des langages de bas niveau tout en gardant l’ecosystème si chère à ces langages (npm, pip, …).
Mon expérience
Après cette introduction rapide à Rust, je préviens tout de suite que j’apprends Rust depuis l’été dernier en lisant "le livre" (en anglais). Je suis en train de créer une crate qui n’est pas loin d’être publiée… quand je trouverais la motivation de le faire 😅.
J’ai un peu regardé comment utiliser async/await
dans d’autres langages mais je n’ai jamais utilisé cette syntaxe moi même. Je n’ai donc pas d’opinion forte sur celle proposé par l’équipe du langage, je me base dessus.
La syntaxe proposée pour await
Donc, pour revenir au sujet de ce billet : l’équipe du langage de Rust a proposé d’introduire une nouvelle syntaxe pour le prochain mot-clé await
. Ils ont choisis la syntax dot await
comme ils l’appellent.
Même si je suis plus habitué à des syntaxes en préfixe (match {}
, if {}
, …) qu’en suffixe, je ne pense pas être compétent pour juger ce débat.
Mon problème avec cette syntaxe
Je ne pense pas que la syntaxe dot keyword
sois parfaite tel quel. Biensûr, si on compare cette écriture à celle des méthodes c’est une version sans parenthèses, et pourquoi pas. Mais dans le même temps c’est exactement la syntax pour accéder à une propriété. Si une fonction retourne une structure : fn get_toto -> struct
, je peux vouloir récupérer seulement une de ses propriété comme get_toto().titi
… et ça ressemble trop à la notation dot await
. Ce n’est peut être pas la façon idiomatique de procéder, mais j’ai déjà bidouillé du JS comme cela.
Ma proposition
Pendant ma lecture de l’article j’ai pensé à utiliser la syntaxe commas await
: toto(),await
mais il se peux que ce ne soit ni pratique, ni fesable puisque la virgule est déjà utilisée pour séparer les arguments, même sans espace.
J’aime l’idée de réserver le !
pour tout ce qu’on peux considérer comme magique dans le langage. Lorsqu’on à besoin de faire quelque chose mais un peu d’aide (du compilateur ?) magique est nécéssaire :
- Une fonction avec un peu de magie ? On a déjà les
macro!()
. - Modifier le comportement d’une fonction ? On discute de
!modifiers
ou plus généralement!keywords
. - Un peu de magie sur des valeurs ? On aura peut-être des
.keyMethods!()
ou!keyMethods()
un jour.
Pendant que j’y suis, s’il vous plait, ne créez pas !match
ni aucune structure de contrôle avec cette syntaxe. Gardez cette écriture exclusivement sans arguments. Vous voulez introduire !await
comme mot-clé puiqu’on ne pourrait pas créer cette fonctionnalité comme fonction/macro/méthode. Alors restez sur votre intention : un mot-clé n’a pas de paramètres. Peut-être qu’on pourrait créer !loop
pour transformer une fonction en boucle infinie voir !panic
ou !unwrap
si on en éprouve le besoin pour… quelque chose. Mais je ne suis même pas sur que je le veuille vraiment.
Si vous voulez que l’un des prochains mot-clé ai des paramètres, alors je préfèrereais que vous utilisiez l’une de mes propositions de méthode et ainsi pouvoir mettre les arguments entre parenthèses. Comme cela l’écriture en suffixe des mot-clés gérés par le compilateur restera constant avec ou sans paramètres.
Commentaires
Pour éviter de vous faire créer un compte juste pour commenter mon blog, je vous invite à commenter cet article sur son annonce dans le Fédiverse, Reddit /r/rust (en anglais).
PS : Syndication
Vous pouvez aussi vous abonner au flux RSS, Atom, ou JSON.