Usability Improvements in GCC 15

Yes, it's definitely nice to be able to typecheck generic code before instantiation. But supporting that ends up adding a lot of complexity to the typesystem.

C++-style templates are sort of like "compile-time dynamic types" where the type system is much simpler because you can just write templates that try to do stuff and if the instantiation works, it works.

C++ templates are more powerful than generics in most other languages, while not having to deal with covariance/contravariance, bounded quantification, F-bounded quantification, traits, and all sorts of other complex machinery that Java, C#, etc. have.

I still generally prefer languages that do the type-checking before instantiation, but I think C++ picks a really interesting point in the design space.

how does it work over ssh? :)

I for one don't think so. From my perspective, there's at least as much momentum in GCC as clang/LLVM, especially on the static analysis and diagnostics front over the past 5 or so years. That was originally one of the selling points for clang, and GCC really took it to heart. It's been 10 years since GCC adopted ASAN, and after playing catchup GCC never stopped upping their game.

Perhaps the image problem is that LLVM seems to be preferred more often for interesting research projects, drawing more eyeballs. But by and large these are ephemeral; the activity is somewhat illusory, at least when comparing the liveliness of the LLVM and GCC communities.

For example, both clang/LLVM and GCC have seen significant work on addressing array semantics in the language, as part of the effort to address buffer overflows and improve static analysis. But GCC is arguably farther along in terms of comprehensive integration, with a clearer path forward, including for ISO standardization.

More importantly, the "competition" between GCC and clang/LLVM is mutually beneficial. GCC losing prominence would not be good for LLVM long-term, just as GCC arguably languished in the period after the egcs merger.

Why not spend time on helping IDEs to understand error messages? That would be billion times more useful.

If a company makes a new MCU with some exciting new instruction set, they need to make a compiler available which supports that instruction set and make that compiler available to their customers.

With LLVM as the base, the vendor could make their toolchain proprietary, making it impossible to integrate it back into LLVM, which means the vendor toolchain will exist until the ISA gets wide-spread enough for volunteers to invest the time required to make a separate production-quality LLVM back-end from scratch.

With GCC as the base, the vendor must at least make their GCC fork available to their customers under the GPL. This, in theory, allows the GCC community to "just" integrate the back-end developed by the vendor into GCC rather than starting from scratch.

Now I don't know how effective this is, or how much it happens in practice that the GCC project integrates back-ends from vendor toolchains. But in principle, it's great that vendors have to make their toolchains FOSS because it reduces the need for vendor toolchains.