Zig 0.17 : ce qui change pour les développeurs

Zig 0.17.0 est disponible depuis le 2 octobre. Cette version du langage système, qui vise à concurrencer C sur son propre terrain, rassemble cinq mois de travail, 925 commits et 206 contributeurs. Au programme : des changements de sémantique qui peuvent casser du code sans prévenir, un système de build réorganisé et une chaîne d'outils mise à jour. Comme toujours avant la 1.0, la migration demande un peu d'attention.

Des changements de langage à surveiller

Le changement le plus délicat concerne @bitCast, qui réinterprète désormais la « représentation logique » des bits d'une valeur. Les conversions impliquant des extern struct ou extern union ne sont plus acceptées : pour faire du type punning, il faut passer par @ptrCast ou une extern union. Les notes de version préviennent que ce changement peut modifier le comportement de certains programmes sans erreur de compilation.

Plusieurs builtins font leur apparition : @backingInt et @fromBackingInt remplacent @intFromEnum et @enumFromInt, désormais dépréciés, tandis que @divCeil ajoute la division arrondie au supérieur et @SpirvType les types SPIR-V. À l'inverse, la multiplication de tableaux (a ** b, à remplacer par @splat), la syntaxe void{}, la capture dans errdefer et le type i0 disparaissent. @hasDecl ne renvoie plus true que pour les déclarations publiques.

Autre retrait notable : @cImport. La traduction de C passe par un paquet externe translate-c, et std.Build.Step.TranslateC est déprécié.

Bibliothèque standard et système de build

Côté bibliothèque standard, le nouvel allocateur SafeAllocator, thread-safe, prend la relève de std.heap.DebugAllocator. StackFallbackAllocator devient BufferFirstAllocator et reçoit son tampon en argument. Un piège est signalé : la fonction containsAtLeastScalar a été renommée puis son nom réutilisé avec des paramètres inversés, si bien que d'anciens appels peuvent encore compiler tout en se comportant mal.

zig build sépare désormais le processus de configuration de celui qui exécute le build, avec un format de configuration binaire. Un Build Server Protocol, activé par --listen=-, permet aux IDE de piloter et surveiller le build, et la gestion des paquets quitte le compilateur pour le système de build. Conséquence pratique : le serveur de langage ZLS ne fonctionne pas encore avec la 0.17.

Compilateur et cibles

La compilation incrémentale devient utilisable pour la plupart des projets x86_64-linux via -fincremental --watch, et le nouveau linker ELF est activé par défaut pour ces builds incrémentaux sur x86_64. Le backend SPIR-V passe au multithread, celui de WebAssembly approche la parité avec LLVM. La chaîne d'outils passe à LLVM 22.1.8, avec musl 1.2.5 et glibc 2.44. Les cibles powerpc-linux-gnueabi et powerpc64-linux-gnu sont abandonnées, et les minimums montent à Linux 5.10 et Windows 10.

Et après ?

La feuille de route de la 0.18 prévoit LLVM 23, la réactivation de la vectorisation de boucles et la suppression de l'ancien linker ELF. La 1.0 reste conditionnée à la stabilisation complète du langage. Pour les équipes qui suivent plusieurs langages système, ce cycle rappelle celui de Rust 1.99 et ses fonctions variadiques C : Rust stabilise, Zig assume encore de casser pour avancer.