9 ms·

I was very curious to see what C++ 26 brings to the table, since I haven't used C++ in a while. When I saw the 'no boilerplate' example, the very first thought

I was very curious to see what C++ 26 brings to the table, since I haven't used C++ in a while. When I saw the 'no boilerplate' example, the very first thought that came to my mind: This is the ugliest, most cryptic and confusing piece of code I've ever seen. Calling this 'no boilerplate' is an insult to the word 'boilerplate'. Yeah, I can parse it for a minute or two and I mostly get it. But if given the choice, I'd choose the C-macro implementation (which is 30+ years old) over this, every time. Or the good old switch case where I understand what's going on. I understand that reflection is a powerful capability for C++, but the template-meta-cryptic-insanity is just too much to invite me back to this version of the language.

SuperV1234 4mo ago
It is "cryptic" and "ugly" to you just because you're not familiar with it. You'd pick the macro-based implementation because you are familiar with it. Seeing this argumentation is so tiresome, because it feels like there is a lack of self-awareness regarding what is "familiar" and what isn't, which is subconsciously translated to "ugly" and "bad".
- delegate 4mo ago
  Have you ever used other (modern) programming languages ? In a lot of languages, you achieve the same with 1 line of code. It's not about familiarity, it's about the fact that it's a long and convoluted incantation to get the name of an enum. Why do I have to be familiar with all those weird symbols just to do a trivial thing ? Update: Zig: const Color = enum { red, green, blue }; const name = @tagName(Color.red); // "red" Rust: #[derive(Display)] enum Color { Red, Green, Blue } let name = Color::Red.to_string(); // "Red" Clojure: (name :red) => "red"
  - SuperV1234 4mo ago
    C++: enum Color { red, green, blue }; auto name = to_enum_string(Color::Red); // "Red"
    - shooly 4mo ago
      ... and where does that `to_enum_string` come from exactly? It doesn't seem to be built-in, which is the point of the parent comment.
      - SuperV1234 4mo ago
        It's a fair comparison. The parent comment isn't showing the compiler source code for the built-in reflection mechanisms. You won't have to care about ^^ and [:X:] if you just want to consume reflection-based utils, which was the whole point of my comment.
        shooly 4mo ago
        What? No. Parent comment is comparing C++ to modern programming languages, showcasing how they provide commonly used utilities out-of-the-box instead of making every programmer re-implement them again and again and again and again and again.
        SuperV1234 4mo ago
        The parent comment is quite clear: > Why do I have to be familiar with all those weird symbols just to do a trivial thing ? And my answer demonstrates that you do not have to.
        shooly 4mo ago
        > And my answer demonstrates that you do not have to Then again - "where does that `to_enum_string` come from exactly?".
        pjmlp 4mo ago
        A library that you install via vcpkg or conan. How many libraries do you read the source code after installing them with the package manager?
  - throwaway7356 4mo ago
    And what if you want to implement something like Rust's "derive"? That is what the article shows. As far as I understand you would have to mess with individual parser tokens in Rust instead of high-level structures like "enum" (C++ reflection). It would be much, much uglier to implement anything like "to_enum_string" in Rust as you would have to re-implement parts of the compiler to get the "enum" concept out of a list of tokens.
- wiseowise 4mo ago
  No, it is objectively cryptic and ugly. I honestly don’t understand how can anyone keep up with this garbage, but the ship has sailed long time ago. It is just a soup of symbols at this point.
  - SuperV1234 4mo ago
    No, it objectively isn't objective.
spacechild1 4mo ago
> But if given the choice, I'd choose the C-macro implementation (which is 30+ years old) over this, every time. Why? The implementation is not pretty, but you only need to write it once and then it works for all enums. The actual usage is trivial, it's just a function call. The C macro version is horrendous in comparison. Why would I want to declare my enums like that just because I might want to print them?
- madduci 4mo ago
  Then why isn't part of the stdlib? Why should everybody maintain their own version?
  - spacechild1 4mo ago
    Just wait for C++32 :-D. After all, we only got `std::string::starts_with` in C++20 and C++23 finally gave us `std::string::contains`. It's a clown show, you just need to take it with humor.
    - madduci 4mo ago
      For comparison, in Java they do much more significant changes each release
vanderZwan 4mo ago
As a developer who doesn't really write C++ code I'm inclined to agree, but I think Herb Sutter's "syntax 2" project might provide a nice way out of that mess eventually. I played around with cppfront over Christmas and it was a lot more ergonomic than my distant memories of C++11, which I don't even have negative memories of per se. [0] https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront
- pjmlp 4mo ago
  That isn't going anywhere official. It is no different from any other language that compiles via C or C++ code generation, it got sold a bit differently due to his former position at WG21.
  - vanderZwan 4mo ago
    Well, if you mean "as an official C++ syntax" then I agree, and I suspect Sutter would agree as well. He labeled one talk about it a "Towards a Typescript for C++", after all[0]. But I do think it is different than other "compile to C++" languages, because it seems to be more of a personal case study for Sutter to figure out various reflection and metaprogramming features, and then "backport" those worked out ideas to regular C++ via proposals. And the latter don't have to match the CPP2 syntax at all. In multiple examples he's given in talks the resulting "regular" C++ code is easier to read, mainly because the metaprogramming deals with so much boilerplate. [0] https://www.youtube.com/watch?v=8U3hl8XMm8c https://www.youtube.com/watch?v=8U3hl8XMm8c
    - pjmlp 4mo ago
      What Herb Stutter misses on his Typescript and Kotlin for C++ metaphor is the actual reality how those languages integrate, unlike cpp2. Typescript is a linter, nothing else, type annotations for JavaScript. The two features that aren't present in JavaScript, enums and namespaces, are considered design mistakes and the team vouched to focus only on being a linter,and polyfill for older runtimes, when possible (some JS features require runtime support). While Kotlin spews JVM bytecode many language constructs, like co-routines, make it one way, it is easy to call Java from Kotlin, the other way around requires boilerplate code, manipulating the additional classes generated by the Kotlin compiler for its semantics.

SuperV1234 4mo ago

It is "cryptic" and "ugly" to you just because you're not familiar with it. You'd pick the macro-based implementation because you are familiar with it. Seeing this argumentation is so tiresome, because it feels like there is a lack of self-awareness regarding what is "familiar" and what isn't, which is subconsciously translated to "ugly" and "bad".

delegate 4mo ago
Have you ever used other (modern) programming languages ? In a lot of languages, you achieve the same with 1 line of code. It's not about familiarity, it's about the fact that it's a long and convoluted incantation to get the name of an enum. Why do I have to be familiar with all those weird symbols just to do a trivial thing ? Update: Zig: const Color = enum { red, green, blue }; const name = @tagName(Color.red); // "red" Rust: #[derive(Display)] enum Color { Red, Green, Blue } let name = Color::Red.to_string(); // "Red" Clojure: (name :red) => "red"
- SuperV1234 4mo ago
  C++: enum Color { red, green, blue }; auto name = to_enum_string(Color::Red); // "Red"
  - shooly 4mo ago
    ... and where does that `to_enum_string` come from exactly? It doesn't seem to be built-in, which is the point of the parent comment.
    - SuperV1234 4mo ago
      It's a fair comparison. The parent comment isn't showing the compiler source code for the built-in reflection mechanisms. You won't have to care about ^^ and [:X:] if you just want to consume reflection-based utils, which was the whole point of my comment.
      - shooly 4mo ago
        What? No. Parent comment is comparing C++ to modern programming languages, showcasing how they provide commonly used utilities out-of-the-box instead of making every programmer re-implement them again and again and again and again and again.
        SuperV1234 4mo ago
        The parent comment is quite clear: > Why do I have to be familiar with all those weird symbols just to do a trivial thing ? And my answer demonstrates that you do not have to.
        shooly 4mo ago
        > And my answer demonstrates that you do not have to Then again - "where does that `to_enum_string` come from exactly?".
        pjmlp 4mo ago
        A library that you install via vcpkg or conan. How many libraries do you read the source code after installing them with the package manager?
- throwaway7356 4mo ago
  And what if you want to implement something like Rust's "derive"? That is what the article shows. As far as I understand you would have to mess with individual parser tokens in Rust instead of high-level structures like "enum" (C++ reflection). It would be much, much uglier to implement anything like "to_enum_string" in Rust as you would have to re-implement parts of the compiler to get the "enum" concept out of a list of tokens.
wiseowise 4mo ago
No, it is objectively cryptic and ugly. I honestly don’t understand how can anyone keep up with this garbage, but the ship has sailed long time ago. It is just a soup of symbols at this point.
- SuperV1234 4mo ago
  No, it objectively isn't objective.

spacechild1 4mo ago

> But if given the choice, I'd choose the C-macro implementation (which is 30+ years old) over this, every time. Why? The implementation is not pretty, but you only need to write it once and then it works for all enums. The actual usage is trivial, it's just a function call. The C macro version is horrendous in comparison. Why would I want to declare my enums like that just because I might want to print them?

madduci 4mo ago
Then why isn't part of the stdlib? Why should everybody maintain their own version?
- spacechild1 4mo ago
  Just wait for C++32 :-D. After all, we only got `std::string::starts_with` in C++20 and C++23 finally gave us `std::string::contains`. It's a clown show, you just need to take it with humor.
  - madduci 4mo ago
    For comparison, in Java they do much more significant changes each release

vanderZwan 4mo ago

As a developer who doesn't really write C++ code I'm inclined to agree, but I think Herb Sutter's "syntax 2" project might provide a nice way out of that mess eventually. I played around with cppfront over Christmas and it was a lot more ergonomic than my distant memories of C++11, which I don't even have negative memories of per se. [0] https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront

pjmlp 4mo ago
That isn't going anywhere official. It is no different from any other language that compiles via C or C++ code generation, it got sold a bit differently due to his former position at WG21.
- vanderZwan 4mo ago
  Well, if you mean "as an official C++ syntax" then I agree, and I suspect Sutter would agree as well. He labeled one talk about it a "Towards a Typescript for C++", after all[0]. But I do think it is different than other "compile to C++" languages, because it seems to be more of a personal case study for Sutter to figure out various reflection and metaprogramming features, and then "backport" those worked out ideas to regular C++ via proposals. And the latter don't have to match the CPP2 syntax at all. In multiple examples he's given in talks the resulting "regular" C++ code is easier to read, mainly because the metaprogramming deals with so much boilerplate. [0] https://www.youtube.com/watch?v=8U3hl8XMm8c https://www.youtube.com/watch?v=8U3hl8XMm8c
  - pjmlp 4mo ago
    What Herb Stutter misses on his Typescript and Kotlin for C++ metaphor is the actual reality how those languages integrate, unlike cpp2. Typescript is a linter, nothing else, type annotations for JavaScript. The two features that aren't present in JavaScript, enums and namespaces, are considered design mistakes and the team vouched to focus only on being a linter,and polyfill for older runtimes, when possible (some JS features require runtime support). While Kotlin spews JVM bytecode many language constructs, like co-routines, make it one way, it is easy to call Java from Kotlin, the other way around requires boilerplate code, manipulating the additional classes generated by the Kotlin compiler for its semantics.