It's a bit more nuanced than that, as detailed by AndyKelley (andrewrk@) on github[1].
As I understand it, C/C++ interop and support in the build system is not going away; instead it might be accomplished via a separately maintained clang package. (Aside: for an example of this kind of thing can work, see ffmpeg[2] converted to use the Zig build system which pulls in nasm[3] as a Zig package; presumably the clang solution would be a bit more integrated than that, but it serves to show that it can be done).
Zig will still support compilation using LLVM, but instead of directly linking to LLVM and using LLVM's IRBuilder API, it will directly output LLVM bitcode instead[4]. The build system will then handle linking this into an executable, possibly by calling out to the LLVM linker.
The idea seems to be to reduce dependencies of the main executable, while keeping the build system flexible enough that it does not impact existing use cases.
I'm not affiliated with the Zig project in any way, so my understanding of this may be off. I'd recommend reading the GH issues and comments I've linked below to get a better idea of it.
- the Zig compiler will get a new integrated C frontend written in Zig
- ...and a new backend which can emit LLVM bitcode (so it's still possible to integrate with an external LLVM toolchain)
- C++ and ObjC compilation (or Clang's specific flavour of C) will be delegated to a package dependency which includes a clang toolchain, accessible through the build system
...so things will be shuffled around, but no functionality will be lost.
They want to remove the dependency on LLVM, but also they plan to keep shipping clang as well, I believe. Probably they will ship 2 different zig binaries, one that is only able to compile zig and c, but without the help of clang, and one that includes clang as well, and can compile c++.