Sandor Dargo

Looks like <stacktrace> is already part of C++23 [0]. But if you must use an older C++, why link the entire Swift runtime rather than something GCC's builtin backtraces [1] or libbacktrace [2]? [0] https://www.sandordargo.com/blog/2022/09/21/cpp23-stacktrace-library [1] https://www.gnu.org/software/libc/manual/html_node/Backtraces.html [2] https://github.com/ianlancetaylor/libbacktrace

> they should simply use c++, like k&r did to compile their example code in their 2nd ed - see preface to book if you don't believe. So what? And GCC allegedly has been C++ for many years. Please take a look at the repo and tell me why anyone cares about that. My personal experience with C++ is that I seem to always end up peeling off my nice abstractions again later. Most of what it offers hasn't stuck for me, at least for systems programming. There's a lot of bad C code I've had to work on over the years, but overzealously architected C++ codebases take the crown for inflicting the most pain for sure. One recent experience was when I replaced 4 files and 200 lines of C++ classes with 4 lines of straight C code. Not even a function was necessary. And that was one of the less bad experiences because it was actually possible to fix. In my most recent attempt to be open-minded about it I've ended up keeping a few short methods, which can be nice for code brevity at the call site, and there is less of a tax about having to come up with naming schemes. But I have otherwise found classes (and in particular methods) to be painful for two reasons: All the procedures operating on the class have to be declared in the class (or as part of a friend class, but then they have to be declared there). This includes private methods and is just one more level of annoyance for a small (and debatable) syntactic convenience. It's pretty f***ing bad to have to turn implementation details to…

To be fair I've mostly used concepts in Nim, not C++ x0 concepts. However, your comparisons of C++ concepts to Rust traits seems to be lacking a lot of details or is plain inaccurate. It also misses the flexibility of C++ concepts. > C++ 0x Concepts was similar to Rust's Trait system in many ways. Particularly notable features of C++ 0x Concepts you might recognise in Rust's traits: Perhaps at the loosest level of comparison around only defining limitations on possible types. However, C++ x0 concepts enable much more powerful combinations of logic to specify if a template fulfills a concept. In Nim the concept can be any arbitrary boolean statement. This blog has some good examples of C++ concepts: https://www.sandordargo.com/blog/2021/03/10/write-your-own-cpp-concept… It's trivial to specify that a C++ concept can be either a float or an integer: template <typename Base, typename Exponent> concept HasPower = (std::integral<Exponent> || std::floating_point<Exponent>) && requires (Base base, Exponent exponent) { base.power(exponent); }; That's not possible AFAICT with Rust's traits. > 1. Third parties can implement a C++ 0x Concept for some type which was not originally conceived with this Concept in mind, they just write the implementation and it works. That's true for C++ concepts, but not entirely true for Rust traits. You can only implement a Rust trait if you own the type or own the trait. If you use two third party libraries, you…