Abandon de l’adoption de Swift – fin de l’issue sur le support de Swift 6.0 dans le navigateur Ladybird

 (github.com/LadybirdBrowser)
1 points par GN⁺ 2026-02-20 | 1 commentaires | Partager sur WhatsApp
  • Le projet de navigateur Ladybird a dressé la liste des problèmes rencontrés lors du passage du support de Swift 6.0 du stade expérimental à un statut officiel, mais a ensuite décidé de ne plus poursuivre l’adoption de Swift
  • Les principaux obstacles concernaient l’interopérabilité (Interop) entre Swift et C++ : incompatibilités d’ABI, dépendances circulaires entre en-têtes, impossibilité de renvoyer certains types, etc. Plusieurs points ont été corrigés après Swift 6.0.0
  • Dans le système de build CMake, des problèmes ont également été signalés dans l’environnement Swift + Ninja, notamment des incohérences de cible de déploiement, des erreurs de traitement de install_name et des options de compilation incompatibles
  • Dans le code de Ladybird lui-même, de nombreuses instabilités de build ont été constatées, notamment autour de la configuration des modulemap des modules AK et LibGfx, des plantages du frontend Swift et des conflits d’espace de noms sur les types
  • En raison de l’accumulation de ces contraintes techniques, l’intégration de Swift a été abandonnée, ce qui a conduit à la décision de conserver un développement centré sur C++

Problèmes liés à Swift

  • De nombreux bugs au niveau du langage et de l’ABI devaient être résolus pour faire sortir le support de Swift 6.0 de la phase expérimentale
    • Échec d’assertion lors d’un build open source de Swift en raison d’un décalage de version LLVM
    • Problème d’incompatibilité d’ABI entre le compilateur et le bridging header lors du retour de Optional<CxxValueType>
    • Sur Ubuntu 22.04, inclusion de l’en-tête <execution> provoquant une dépendance circulaire de module dans libstdc++
    • Problèmes de compatibilité C++23, notamment impossibilité de renvoyer swift::Optional<swift::String> et échec du chargement de l’en-tête <chrono>
  • Certains problèmes ont été corrigés dans des versions publiées après Swift 6.0.0, mais d’autres ne l’ont été que sur la branche main, sans être intégrés à une version stable
  • Plusieurs points proposaient des « workarounds (méthodes de contournement pour le build) », sans que cela constitue une solution complète

Problèmes liés à CMake

  • Avec la combinaison Swift et Ninja build, CMAKE_OSX_DEPLOYMENT_TARGET n’était pas appliqué, ce qui générait de nombreux avertissements
    • Il fallait définir manuellement CMAKE_Swift_COMPILER_TARGET
  • Quand la politique CMP0157 est activée, la configuration du répertoire install_name est ignorée, ce qui impose une correction manuelle
    • Le correctif correspondant doit être backporté dans CMake 3.29 et 3.30
  • Des options de lien que le compilateur Swift ne comprend pas peuvent être transmises par des dépendances externes

Problèmes internes au projet Ladybird

  • Lors de la configuration des clang module map des modules AK et LibGfx, des conflits avec les en-têtes système se produisent
    • L’inclusion de <math.h> entraîne un échec du build à cause d’une erreur de reconnaissance de module
  • Le frontend Swift plante sur des builds debug pendant les tests des conteneurs AK
    • Le problème ne peut être contourné qu’en buildant en mode release
  • Un conflit d’espace de noms autour du type String provoque un arrêt anormal du frontend Swift
    • Il faut l’indiquer explicitement comme AK.String ou Swift.String
  • Lors de l’utilisation du module Swift Testing, on observe des plantages du frontend du compilateur, ainsi qu’un problème de non-reconnaissance de CxxSequenceType pour AK::StringView

Éléments d’amélioration supplémentaires

  • Quand une fonction C++ renvoie Optional<CxxType> vers Swift, l’application plante
    • Une solution temporaire consiste à renvoyer un tableau de taille 0 ou 1
  • SourceKit-LSP et vscode-swift exigent un compile_commands.json à la racine
    • Le problème peut être résolu par la création d’un lien symbolique
  • Sous Linux, il est contraignant de devoir ajouter manuellement le chemin <swift/bridging>

Questions non résolues

  • On ne sait pas clairement comment, en Swift, transmettre sans copie un type view C++ ou un byte slice
  • Swift ne reconnaît pas les types maison comme AK::Optional ou AK::HashMap comme équivalents aux types std::
  • La manière d’intégrer le garbage collector de Swift avec la gestion mémoire de Ladybird reste également indéterminée

Cette issue était un document consignant de manière structurée les obstacles techniques à l’intégration de Swift 6.0, mais après l’abandon de l’adoption de Swift par l’équipe Ladybird, l’issue « Swift 6.0 Blockers » a été clôturée.

À lire aussi

1 commentaires

 
GN⁺ 2026-02-20
Commentaires sur Hacker News

  • Le commit qui supprime Swift contient quelques explications supplémentaires
    Il inclut le message : « Après une longue période sans progrès, nous abandonnons l’adoption de Swift et le retirons de la base de code »
    Le commit concerné peut être consulté ici

  • J’ai essayé Swift pour la première fois en 2021, après plus de 10 ans sur C#/.NET, et ça m’a surpris
    Je trouvais déjà C# complexe, mais Swift était un langage encore plus complexe
    En particulier, il n’y avait presque aucune ressource de référence pour créer des API backend ou des couches d’accès aux données
    Les connaissances sur Swift sont surtout accumulées pour les plateformes Apple, donc en dehors de ça on a presque l’impression de devoir être un pionnier

    • Ces dernières années, des langages simples comme Python ou Go ont renforcé l’idée que « la complexité est mauvaise », mais je pense qu’une forte expressivité du langage peut au contraire aider à la maintenance
      Comme l’a dit Larry Wall, la complexité des outils doit correspondre à celle du problème (avec une référence à Raku)
    • Je suis passé d’Objective-C à Swift vers 2018, et au début ça m’a semblé être une amélioration
      Mais des règles comme « les struct sont passées par valeur, les class par référence » entraient en conflit avec le principe d’une « source unique de vérité », ce qui rendait le développement fastidieux et lent
      À cause des bonnes pratiques contradictoires de Swift, je n’avançais pas, et j’ai fini par comprendre qu’une grande partie des conseils n’étaient pas fiables
    • J’avais aussi un problème où mon ordinateur portable surchauffait à chaque compilation d’un template Vapor sur un MacBook M1
    • Même ressenti pour moi. Je pensais l’apprendre vite, comme Rust, mais pas du tout
      Il y a trop de sucre syntaxique, et des dizaines de façons de faire la même chose, donc il fallait consulter la référence du langage en permanence
    • Du coup, je me demande si tu es finalement revenu à C#/.NET

  • Quel que soit le langage, j’espère que Ladybird se concentrera plus tard sur une implémentation de JavaScript conviviale pour l’utilisateur
    Le fait que JS soit utilisé pour suivre l’activité des utilisateurs, bloquer le collage ou collecter trop d’informations sur l’appareil est un vrai problème
    Comme Tor, signaler des valeurs d’usurpation standardisées entre utilisateurs pourrait aider à protéger la vie privée

    • Mais ce type d’approche risque d’être pris pour de la détection de bots sur de nombreux sites web, avec blocage d’accès à la clé
      En faire une option activable me semble acceptable, mais en faire la valeur par défaut compliquerait sans doute l’adoption
    • Personnellement, je n’aurais absolument pas envie d’utiliser un navigateur qui ignore les standards du web et fonctionne à sa manière

  • La suppression de Swift est intéressante. Les raisons ne sont pas expliquées clairement, donc je suis curieux
    Si ça fonctionne au moins sous Linux, j’essaierai peut-être plus tard

    • À mon avis, ils ont abandonné à cause de conflits de build répétés
      Swift ne pouvait peut-être pas importer plusieurs bibliothèques de versions C++ différentes en même temps, ou il y avait des conflits de versions d’opérateurs
      Swift est un bon langage, mais l’ajouter après coup à un gros projet devait sans doute être trop compliqué

  • Je me demande pourquoi Ladybird a essayé Swift. J’aurais pensé que Rust avait une meilleure interopérabilité avec C++
    Le GC de Swift me semble aussi défavorable aux performances d’un navigateur

    • Andreas Kling a mentionné sur Twitter que, entre « Swift vs Rust », Swift était meilleur pour le support orienté objet et l’intégration C++
      lien1, lien2
    • C’est similaire aux raisons pour lesquelles Rust est peu pratique en développement de jeux. Le borrow checker s’accommode mal des structures à références circulaires
      Il existe des contournements, mais ils réduisent la productivité
    • Swift a en réalité une interopérabilité assez bonne, comme indiqué dans la documentation sur l’interop C++
      Mais cela n’a apparemment pas suffi pour Ladybird
    • Andreas Kling a dit que Rust était désavantagé pour le développement d’interfaces graphiques parce qu’il manque de fonctionnalités orientées objet
      Il avait aussi créé autrefois un langage appelé Jakt dans SerenityOS, mais il semble qu’il soit finalement revenu au C++
    • Il me semble que Rust avait déjà été écarté à cause de la hiérarchie DOM ou de problèmes liés à l’OOP
      Une ancienne discussion connexe se trouve dans ce billet

  • Il n’est pas surprenant que Swift soit un langage trop dépendant d’Apple
    Il suffit d’utiliser correctement les parties sûres de C++, et de toute façon la plupart des navigateurs sont écrits en C++

    • Sauf que tous les navigateurs sont simplement coincés en C++
      Chromium et Firefox remplacent progressivement certaines parties par des langages plus sûrs, et réécrire un nouveau navigateur en C++ reviendrait à répéter les erreurs du passé
      L’usage de C++ est un héritage de l’époque de KHTML en 1998
    • Je ne vois pas très bien ce que serait concrètement un « sous-ensemble moderne de C++ sûr pour la mémoire »
      Est-ce que ça inclut des fonctionnalités STL récentes comme string_view ? On reste de toute façon loin d’une vraie sécurité mémoire complète
    • Je crois que Rust a été développé chez Mozilla, mais je me demande si Mozilla lui-même est écrit en Rust
    • De toute façon, Swift a du mal à battre C++ dans les domaines qui exigent de hautes performances
      En dehors de quelques benchmarks, dans les vrais programmes il est presque toujours plus lent

  • Dommage que Swift soit retiré. Je me demande si leur langage maison Jakt redevient un candidat

    • Ladybird est déjà séparé de SerenityOS, et Jakt n’est pas leur langage
      Je pense qu’il est peu probable qu’ils introduisent un nouveau langage
    • Personnellement, ce qui m’inquiète, c’est que le projet change trop souvent de direction
      Pour un projet financé par des soutiens externes, fonctionner ainsi risque d’être difficile à tenir sur le long terme
    • Je ne comprends pas pourquoi ils n’utilisent pas Rust. Je me demande si ce n’est pas une forme de fixation sur le C++

  • À la fin, je pense que Swift n’est rien d’autre qu’un langage-jouet d’Apple
    Apple ne le laissera pas devenir davantage que ça

  • L’interface Mac de Ladybird est une fine couche posée sur AppKit
    Elle est écrite en Objective-C++, pas en Swift
    Voir le code source

    • C’est moi qui ai écrit ce code au départ
      C’était bien avant l’adoption de Swift, à l’époque de SerenityOS, donc j’ai utilisé Objective-C++ simplement parce que c’était un langage familier

  • J’avais critiqué le passage à Swift à l’époque
    Je trouvais que Swift avait une conception maladroite, une vitesse de compilation lente, et peu de chances de devenir un vrai langage système
    Comme il n’y avait pas de spécialistes, je pense que cette décision a été la bonne

    • Swift donne l’impression d’être open source, mais en réalité Apple garde tout le pouvoir de décision
      Des fonctionnalités comme la concurrency ou Swift Testing ont aussi été poussées en fonction des besoins d’Apple
      Le travail cross-platform est en grande partie mené séparément par de petites équipes
    • Je reconnais les problèmes de Swift, mais dire qu’« il n’y avait pas de spécialistes » est exagéré
      Même en dehors de Chris Lattner, les leads de Swift étaient des personnalités reconnues dans la communauté C++
    • Le cœur de Swift, ce n’est pas tant le langage lui-même que son ABI standard
      J’aimerais que le camp Rust prenne aussi en charge l’ABI de Swift en FFI, avec celle du C
    • Dans ce cas, quel langage recommanderais-tu ?
    • Go, c’est similaire ? J’aimerais savoir quelle est aujourd’hui l’option qui fait le plus consensus