Have you seen some of his recent talks? Lots of underpinnings of cppfront have been added or are in committy.
He compares it to the JS/TS relationship.
Nope, that is mostly sales pitch, the only thing added thus far has been the spaceship operator.
He also sells the language differently from any other language that also compiles to native via C++, like Eiffel and Nim among others, due to conflict of interest to have WG21 chair propose yet another take on C++.
It's not really a valid comparison though. cppfront is a different language that just happens to be compatible with C++. ts/js is were ts is just js with types. You can comment out the types and it just runs. cppfront's language you'll actually have to re-write the code to get it to compile in C++
typescript
function add(a: number, b: number): number { return a + b };
function add(a/*: number*/, b/*: number*/)/*: number*/ { return a + b };
add: (a: float, b: float): float = { a + b; }
float add(float a, float b) { return a + b; }> ts/js is were ts is just js with types. You can comment out the types and it just runs.
Is this true in the general case? I thought there were typescript features that didn't have direct JavaScript alternatives, for example enums.
Enums and namespaces are the only runtime features of TypeScript.
So, yes, you can't just strip types, but it's close.
Is there a comprehensive list of such incompatibilities documented somewhere?
That's not the same.
That guarantees that the types do not determine the output (e.g. no const enums), not that you can "strip" types to get the same output.
Not that I'm aware of.
Decorators would be another example. (Though they have always been marked experimental.)
And of course JSX, but that's not a TypeScript invention.
Do you realize that the Typescript example contains strictly more information than the Javascript one (namely, declarations for the type of three things) and is therefore more complex to compile, while the two C++ examples are semantically identical (the last expression in the function is returned implicitly without having to write "return") and the new syntax is easier to parse?
There are several semantic differences between Cpp1 and Cpp2. Cpp2 moves from last use, which is the biggest one. In a contrived example, that could result in a "hello world" changing to "goodbye world" or any other arbitrary behavior change you want to demonstrate. Cpp2 also doesn't require you to order functions and types or declare prototypes, which means partial template specializations and function overloads can produce similar changes when migrating from Cpp1 to Cpp2.
I've written a little demo here: https://godbolt.org/z/xn1eqd5zb
You can see where CPPFront inserts a `cpp2::move` call automatically, and how that differs from a superficially equivalent Cpp1 function.
yes, of course. That's not my point. My point is TypeScript succeeds because it's just JavaScript with types. It's not a new language. cppfront is an entirely new language so it's arguably going to have a tougher time. Being an entirely new language, it is not analogous to typescript
> He compares it to the JS/TS relationship.
OP is right, TypeScript is a whole new syntax, and it's shtick is that it can be transpiled into JavaScript.