It's your language so do whatever you want but please adjust the branding accordingly...
It's your language so do whatever you want but please adjust the branding accordingly...
Im guessing you'll have two categories of tier 1 support: - Built-in tier 1 support. - Tier 1 support through the optional LLVM backend.
If they already have tier 1 support for an architecture, I don't see why they'd loose that support when they make the LLVM backend an optional dependency?
And as Andrew writes in the proposal, this way might provide a path for better support for more obscure architectures. I would happily work on a backend for Zig for some interesting processor architecture. No way I will ever contribute to LLVM. Working with C++ in not something I'll ever do to fun
To what benefit? Isn't this a waste of resources?
It will NOT reimplement everything, if you read the proposal, it's in favour of changing the LLVM dependency (the libs) not dropping LLVM IR generation, this will come with performance regression since now will be up to the team to get the correct IR, and making decisions LLVM IR generation does already in LLVM
The problem is that clang is being dropped, which means, unless we have a new C++ front made in zig (a-la AroCC for C) we are gonna suffer quite a bit for projects using C++ with zig.
Writing a C++ compiler is several order of magnitude more complicated than writing a C, Java, Go or Zig compiler. There's a very good reason there are only 3 in existence despite how ubiquitous C++ is (and even then, it takes years for them to keep up with the latest standards). C++'s grammar is type 0, there's isn't even an EBNF definition of it because it's pratically impossible to write a complete one. Clang only succeeded thanks to massive investments from the biggest players in the industry, and GCC/MSVC simply grew alongside the language. All other C++ compilers died a horrible death a long time ago.
There are essentially only four extant C++ front-end implementations: GCC, Clang, MSVC, and EDG. All other C++ compilers are based on one of these four implementations, or have since gone extinct. (Except maybe Green Hills, but I can't recall anymore if their front-end is still in-house.)
that seems a monumental undertaking.
People know that, but it's difficult to avoid using it for real things once you've tried it and it works :D.
I haven't done that with Zig, but with Kotlin things like serialization/coroutines/kotest/KAPT (it was the same feeling: oh this stuff is "Experimental" but so cool, I can't do real Kotlin without them!!)... well yeah, I spent many hours rewriting stuff due to that, and totally acknowledge that was on me.