Swift अपनाना बंद — Ladybird ब्राउज़र में Swift 6.0 सपोर्ट इश्यू बंद

• Ladybird ब्राउज़र प्रोजेक्ट ने Swift 6.0 सपोर्ट को प्रयोगात्मक चरण से औपचारिक रूप से अपनाने की प्रक्रिया में सामने आए मुद्दों की सूची तैयार की थी, लेकिन बाद में Swift अपनाने को आगे न बढ़ाने का फैसला किया
• मुख्य बाधाएँ Swift और C++ interoperability (Interop) से जुड़ी ABI असंगतियाँ, header circular dependency, कुछ types को return न कर पाना जैसी थीं, और इनमें से कई मुद्दे Swift 6.0.0 के बाद ठीक किए गए
• CMake build system में भी Swift + Ninja वातावरण में deployment target mismatch, install_name हैंडलिंग त्रुटि, incompatible compiler options जैसी समस्याएँ रिपोर्ट हुईं
• Ladybird के अपने कोड में भी AK और LibGfx modules के modulemap configuration, Swift frontend crash, type namespace conflict सहित कई build instability पाई गईं
• इन जमा हुई तकनीकी सीमाओं के कारण Swift integration रोक दी गई, और इसका परिणाम C++-केंद्रित development बनाए रखने के निर्णय के रूप में निकला

---

Swift से जुड़ी समस्याएँ

• Swift 6.0 सपोर्ट को प्रयोगात्मक चरण से बाहर लाने के लिए हल किए जाने वाले language और ABI स्तर के bugs बड़ी संख्या में मौजूद थे
  • LLVM version mismatch के कारण Swift open source build के समय assertion failure होता था
  • Optional<CxxValueType> return करने पर compiler और bridging header के बीच ABI mismatch समस्या
  • Ubuntu 22.04 वातावरण में <execution> header शामिल करने पर libstdc++ module circular dependency होती थी
  • swift::Optional<swift::String> return न कर पाना, <chrono> header लोड न होना जैसी C++23 compatibility समस्याएँ भी शामिल थीं
• कुछ समस्याएँ Swift 6.0.0 के बाद की releases में ठीक हुईं, लेकिन कुछ केवल main branch में ही हल हुईं और stable version में शामिल नहीं हुईं
• कई मदों में “workaround (वैकल्पिक build तरीका)” सुझाया गया, लेकिन यह पूर्ण समाधान नहीं था

CMake से जुड़ी समस्याएँ

• Swift और Ninja build संयोजन में CMAKE_OSX_DEPLOYMENT_TARGET लागू न होने से कई warnings आती थीं
  • CMAKE_Swift_COMPILER_TARGET को manually सेट करना पड़ता था
• CMP0157 policy सक्षम होने पर install_name directory setting अनदेखी हो जाती थी, इसलिए manual correction की ज़रूरत पड़ती थी
  • संबंधित fix को CMake 3.29, 3.30 में backport करने की योजना थी
• Swift compiler जिन link options को समझ नहीं पाता, वे external dependencies से pass होने की समस्या भी मौजूद थी

Ladybird प्रोजेक्ट के अंदरूनी मुद्दे

• AK और LibGfx modules के clang module map configuration के दौरान system headers से conflict होता था
  • <math.h> शामिल करने पर module recognition error के कारण build fail हो जाता था
• Swift frontend AK container tests के दौरान debug build में crash हो जाता था
  • केवल release mode build से ही इससे बचा जा सकता था
• String type namespace conflict के कारण Swift frontend असामान्य रूप से बंद हो जाता था
  • AK.String या Swift.String के रूप में explicitly निर्दिष्ट करना पड़ता था
• Swift Testing module इस्तेमाल करने पर compiler frontend crash होता था, और AK::StringView के लिए CxxSequenceType को न पहचानने की समस्या भी थी

अतिरिक्त सुधार बिंदु

• Swift में जब C++ function Optional<CxxType> return करता था, तो application crash हो जाता था
  • अस्थायी समाधान के रूप में size 0 या 1 के array return करने का उपयोग किया गया
• SourceKit-LSP और vscode-swift को root स्तर पर compile_commands.json चाहिए होता था
  • symbolic link बनाकर इसे हल किया जा सकता था
• Linux वातावरण में <swift/bridging> path को manually जोड़ना पड़ने की असुविधा भी थी

अनसुलझे प्रश्न

• Swift में C++ के view type या byte slice को बिना copy किए पास करने का तरीका स्पष्ट नहीं था
• Swift AK::Optional, AK::HashMap जैसे अपने types को std:: types के बराबर नहीं पहचान पाता था
• Swift garbage collector और Ladybird की memory management को integrate करने का तरीका भी तय नहीं था

---

यह इश्यू Swift 6.0 integration के लिए तकनीकी बाधाओं को व्यवस्थित रूप से दर्ज करने वाला दस्तावेज़ था, लेकिन बाद में Ladybird टीम ने Swift अपनाना बंद कर दिया, और “Swift 6.0 Blockers” इश्यू बंद कर दिया गया।