While it would obviously be nice to error at compile time, the docs of the slice type clearly say the code mudt panic in this case. Depending on the context, [T; 3] may be better
I don't know what motivate you to keep repeating this narrative, Clang currently have good support of C++23 while MSVC have none[1], if your emphasis is on the standard library side, Clang is the only one that is compatible to all three major implementations and do use libstdc++ and MS STL on their respective "main" platforms.
Also, why isn't Microsoft in the "profit from Clang" list? Is Clang-CL not shipped in Visual Studio Installer? Did they find a way to compile Edge with VC++?
Who exactly cares about C++20? Most (mis)features of the “standard” won’t be used for years anyway, until the codegen stabilizes and performance impact will be known. Most of people in these communities never got a dollar for a line of C++, and people who did rarely express their opinion (but you can still find it online if you try)
Good to mention Microsoft is also depending on Clang for a lot of things (Microsoft is also quietly pushing devs to use Clang-Cl, as MSVC has really showed its age and is still notorious for bad error messages and subpar compiler optimizations…)
Some console vendors are also depending on it as well (Sony, Nintendo). Clang really is the most important C++ project of all time, because it’s the only compiler that’s truly cross-platform (Windows, Mac, Linux, iOS, Android, game consoles, etc…) And recent failures in it catching up with C++20 should be very alarming.
Have you tried converting iterations to SIMD and using vector extension to target x86, ARM, Webassembly and compile for Linux/Windows/MacOS with a simple piece of code? It's a pretty significant speed up and it only work with Clang.
These are great questions! We think our approaches are complimentary. We think that CIR, or ClangIR, can be a codegen target from a combination of our high-level IR and our medium-level IR dialects.
Our understanding of ClangIR is that it has side-stepped the problem of trying to relate/map high-level values/types to low-level values/types -- a process which the Clang codegen brings about when generating LLVM IR. We care about explicitly representing this mapping so that there is data flow from a low-level (e.g. LLVM) representation all the way back up to a high-level. There's a lot of value and implied semantics in high-level representations that is lost to Clang's codegen, and thus to the Clang IR codegen. The distinction between `time_t` and `int` is an example of this. We would like to be able to see an `i32` in LLVM and follow it back to a `time_t` in our high-level dialect. This is not a problem that ClangIR sets out to solve. Thus, ClangIR is too low level to achieve some of our goals, but it is also at the right level to achieve some of our other goals.
I have fond memory of booting OpenBSD the first time last year on an AMD RDNA GPU, after installation a simple "fw_update" got me a hardware accelerated graphic environment going. Very impressive in my book.
https://godbolt.org/z/M7Gr3TazE