Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
libCat
🐈⬛ A runtime for C++26 w/out libC or POSIX. Smaller binaries, only arena allocators, SIMD, stronger type safety than STL, and value-based errors!
-
Interoperable ABI: https://github.com/rust-lang/rust/pull/105586
Yeah, C++ supports higher kinded types through template templates (I'm not sure why the other poster said it doesn't), however it quickly becomes messy and impractical. Here's a cursed library that attempts to support Haskell-style programming in C++. Here's an example where they implement a monad transformer using the only example of a template template template that I have ever seen in the wild.
It's worse in the standard library than it has to be. When I refactored my traits to minimize template instantiations and lean on concepts as much as possible, I measured over 30% improvement to clean build compile times. It's not possible for the standard to do this, because it would subtly change the API. For instance, you can't instantiate or take the address of a concept, but you can for a type-trait class. No reason you'd want to do that, but you can, so they can't "break" the standard library by optimizing this.
By making your code have some semantics (even panicking has defined semantics). C++ UB is characterized by having no semantics. Giving your code clear runtime semantics, a small-step description of what happens when you execute expression X, is what enables robust and provable static analysis in the first place. So indeed there are proof checkers, such as this, that allow you to ensure that code is panic free (i.e. bounds are actually never executed).