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

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.

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

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.

My point was that TypeScript isn't exactly about to replace JavaScript, which was what you were arguing. I'm honestly not sure what you're trying to argue now.

Like, yeah, what you say about TS and Kotlin is true about TS and Kotlin. But since you're not explaining what cpp2 does or plans to do differently, and why it matters, I'm not sure where you're going with that. It's probably obvious but I'm not getting it.

The metaphor Sutter was going for, as I see it, is that TS and Kotlin both added missing features to their host language. Most importantly reflection and decorators in TS, which are now becoming a standard in JS as well[0]. cpp2 mainly focuses on experimenting with reflection and metaprogramming as well, adding features currently missing in C++ by being a compiles-to-C++ language. Sutter has written C++ proposals what would allow give C++ similar reflection and metaprogramming capabilities based on what he discovered by working on cpp2. That's pretty comparable if you ask me.

[0] https://github.com/microsoft/reflect-metadata

> 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?

Then why isn't part of the stdlib? Why should everybody maintain their own version?

For comparison, in Java they do much more significant changes each release

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"

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.

C++:

  enum Color { red, green, blue };
  auto name = to_enum_string(Color::Red); // "Red"

... 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.

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.

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.

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?

So it is NOT built-in and the code example shown above is dishonest - @SuperV1234 compares how "lean" two languages are but conveniently hides half of the code in their preferred language to make it seem simpler that it actually is, as otherwise it would look bad in the comparison!

Reflection is built in, the support is there, anyone can make a left pad out such simple snippet.

> Reflection is built in

Can you quote the C++ standard section that specifically talks about the `to_enum_string` function?

Some people like to really be obtuse on purpose.

It is on the same place as left pad on ECMA 262.

Don't put assumptions in others heads.

First of all, the only correct way to use package managers is with validated internal repos, don't vibe install, that goes for node, and goes for C++ as well.

Second this thread was all about how code lands in one's computer.

Package? We're suggesting to copy paste 5 lines and stick them into a header.

You can press 'parent' button my comment.

Header files are libraries as well.

  #include "to_enum_string.h"

You don't have to understand it to use it. Even then, it's not that hard to understand, it just looks unfamiliar.

So finally, it's NOT built-in, and the parent comment was showing that in other languages - it IS built-in. So your code example is NOT correct and comparison is NOT correct, because you just hid the most important part of it, which is the implementation, that the user has to either: a) write themselves, b) find somewhere on the Internet.

So? The original argument was about the "ugly" syntax that the user didn't want to interact with nor read. I proved that there's no need to do so to consume reflection utils.

XD.

The whole point of reflection is that it doesn't have to be builtin.

No, it objectively isn't objective.