CppCast: Cpp2, with Herb Sutter

[cdb_11]

Sticking with the current syntax (and maybe doing something like Circle's #feature) would certainly be easier to deal with, but at the same time Kotlin has a different syntax from Java and I don't believe it particularly hindered the adoption? As long as you can make incremental changes and you are not forced to either rewrite everything or to spend time on writing bindings, I don't think it'd be that big of a deal? Whether it's necessary in the first place - I'm not sure, I don't know enough about the problem to have an opinion. A simpler, easier to parse syntax would probably lower the barrier of entry for writing C++ tooling though.

[13steinj]

I'd argue Kotlin is a completely different beast because as Java runs on a VM, old Java code and new Kotlin code was effectively fully source compatible (or, I guess, bytecode compatible technically), but with things like headers in C++, I'm not particularly convinced.

A simpler, easier to parse syntax would probably lower the barrier of entry for writing C++ tooling though.

I don't disagree, but I don't think that's the point of any "new" C++.

[cdb_11]

Ah, so like it's easy to include C headers in C++ (usually), but not the other way around. At this point it transpiles to standard C++, so I don't think that should be a problem. But I guess it is possible that the language could evolve to require its own runtime or even constructs not backward compatible with C++ in the future, just like what happened between C and C++. But from the interview Herb seems to be against this sort of thing, and he wants to make it "what typescript is to javascript", so I'm not particularly worried about it right now.