Microsoft veut un C# plus sûr sans le transformer en Rust

Le chef de produit .NET, Richard Lander, a écrit un long article décrivant comment l’équipe entend améliorer la sécurité de la mémoire de C# en introduisant un nouveau modèle et en redéfinissant le mot-clé unsafe existant, rendant le langage plus proche de Rust, sans pour autant renoncer à la gestion automatique de la mémoire.

« Nous envisageons un avenir dans lequel C# fera partie d’un ensemble de langages choisis et notés pour l’application de la sécurité des types et de la mémoire », a déclaré Lander.

De nombreux développeurs C# n’utilisent jamais dangereux, mais il fait partie du langage depuis sa première version. « Écrire du code dangereux, c’est comme écrire du code C dans un programme C# », disait un premier livre intitulé The C# Programming Language, écrit par son inventeur Anders Hejlsberg et d’autres. Les exemples de cas où un code dangereux est nécessaire incluent l’interopérabilité avec le système d’exploitation sous-jacent, l’accès aux périphériques mappés en mémoire ou la mise en œuvre de code à temps critique. Le code non sécurisé permet l’utilisation de types de pointeurs, qui ne sont pas suivis par le garbage collector .NET, et par les opérateurs de pointeurs. En dehors de cela, le modificateur unsafe existant n’a aucun effet sur un type ou un membre.

Cela changera dans C# 16, qui sera disponible en deux versions dans le futur et sera publié fin 2027, selon le cycle annuel .NET habituel, avec .NET 12, qui sera une version avec support à long terme (LTS). Les développeurs peuvent également s’attendre à une version préliminaire en C# 15 et .NET 11.

Dans le nouveau modèle, marquer une méthode comme dangereuse « la marquera également comme require-unsafe, ce qui signifie que les appelants doivent être dans un contexte dangereux et que les remplacements ne peuvent pas être dangereux si les membres de base sont sûrs », indique la proposition de langage actuelle. Cela signifie que la désignation non sécurisée se propage aux appelants jusqu’à ce qu’elle soit supprimée en incluant un contexte non sécurisé dans une méthode, mais sans marquer la méthode comme non sécurisée.

Certains se demandent pourquoi l’équipe s’appuiera sur l’absence de risque pour supprimer la propagation, plutôt que d’utiliser le modificateur de sécurité. « J’ai défendu l’équipe de conception justement pour cela », a déclaré Lander.

Il ne sera plus possible de marquer un type comme dangereux ; la portée non sécurisée se déplace vers les méthodes, propriétés et champs individuels.

Un autre changement est que l’utilisation de types de pointeurs et de certaines expressions de pointeurs ne sera plus considérée comme dangereuse ; il s’agit uniquement de déréférencer un pointeur et donc d’accéder à une mémoire non gérée qui nécessitera un contexte non sécurisé.

Les modifications seront opt-in pour C# 16, ce qui signifie que les développeurs peuvent continuer avec le modèle C# 1.0, mais les bibliothèques d’exécution .NET seront opt-in, a déclaré Lander. De plus, Microsoft envisage d’ajouter des badges sur les packages dans NuGet, le référentiel de packages .NET, pour indiquer s’ils ont accepté et encourager leur adoption. Une future version de C# pourrait entraîner la désactivation du modèle. « Notre intention est de faire du nouveau modèle de sécurité C# la nouvelle norme », a déclaré Lander.

L’idée n’est pas de rendre le code non sécurisé moins dangereux, mais plutôt de le rendre plus visible et plus facile à examiner. Cela s’étend à la documentation de sécurité, via un commentaire sur un membre non sécurisé qui définit un contrat pour son utilisation, qui sera encouragé par les analyseurs de code statiques.

Jusqu’à présent, la réaction des développeurs est largement positive. « Je suis à la fois un développeur C# et Rust, et je l’apprécie vraiment… Je ne détesterais pas que C# se rapproche d’un Rust géré », a déclaré l’un d’eux.

Une chose étrange à propos de cette proposition est que les développeurs C# travaillant sur des applications métier ne remarqueront aucun changement, car ils n’utilisent jamais de code dangereux. Néanmoins, Lander a déclaré que « cette fonctionnalité fait partie des changements les plus puissants que nous puissions apporter » pour améliorer la confiance dans la sécurité du code C#. ®