6 ms·

Pros: - Transpiling to C++ means it will work wherever C++ works. On any toolchain. With relatively little effort. It shouldn't be hard to add CMake and bazel

Pros: - Transpiling to C++ means it will work wherever C++ works. On any toolchain. With relatively little effort. It shouldn't be hard to add CMake and bazel support, for instance. Even mostly dumb makefiles should be workable. - Approaching the community this way could avoid fracturing the community more than it already is. - Targeting specific success metrics (like CVE causes) could provide focus around design and requirements - Seems simpler and easier to learn and teach. Cons: - The pitch assumes C++ modules are implemented, ready to use, and reasonable accessible. - There will be a lot of tooling to reinvent: static analyzers, syntax highlighters, etc. - At least for a while, debugging cpp2 problems will involve juggling multiple parallel realities: cpp2 code, C++ code, and actual program behavior (i.e. compiled binaries). - Doesn't address other major C++ ecosystem problems like build times, packaging, build systems, etc. cpp2 could make them slightly worse.

lbhdc 4y ago
In his talk he demos mixing syntax 1 and 2 (his terms) in the same file. Preprocessor macros work fine unless you enable "pure" mode. He also demos error messages, and was able to get errors from a cpp compiler (msvc) that point to his cpp2 file with a line number and readable error.
mort96 4y ago
This is all true, but I feel it sort of misses the point a bit. The goal seems to be mainly to use cppfront as a test bed for new language syntax and semantics, where most of the ideas will eventually make its way into the C++ standard or into existing compilers. The main reason to use it in production is that it's not meant to be used in production and makes no attempt to be suitable for production use or avoid breaking changes, so the stuff in your cons list doesn't really apply. It's kind of like looking at someone's scale model of a proposed city layout and say that a pro is that tiny plastic houses are cheap to manufacture at scale but a con is that the houses may be too small to live in. But all of your points will become relevant if cppfront eventually gets to a state where it's a serious transpiler meant to be used in production.
- kvathupo 4y ago
  I agree, and would like to note that there isn't a need to simplify C++ imo. It's folly from a business and productivity standpoint to use one language, especially C++, to do everything from writing web apps to doing exploratory data analysis. Besides, the C++ community seems to overlap with academia by way of its feature updates, reveling in complexity (e.g. "C++20 ranges are totally awesome: memory-safe and performant iterators!").
- eslaught 4y ago
  I don't think this analogy quite works. If all you wanted to do was evolve the existing C++, then sure, you wouldn't need any of this to be remotely production ready. But to me, part/most of what makes this interesting is the possibility for backwards-incompatible, radical simplifications to the C++ syntax and/or feature set. Those really are only meaningful if they get to a production ready state. And by being backwards-incompatible, they inherently cannot just be bolted onto the existing C++ language spec (as if we wanted to anyway---the spec is far to complex as it is). I will say that it's impressive how much of this has already made it into C++ language specs. But given that Sutter has chosen to release this now, I get the sense that of what remains, large portions cannot continue to simply be done that way.
zozbot234 4y ago
> Transpiling to C++ means it will work wherever C++ works. It also means you don't really benefit from any of the new semantics. Why do all of that static analysis work to establish safety, and then throw the results away by writing out clunky old C++? It all makes very little sense.
- zdragnar 4y ago
  Transpiling and compiling are turtles all the way down. It's a bit more complicated than, say, typescript to JavaScript, but in spirit is not so very different, right?
- wasyl 4y ago
  Because you don't actually work with the C++ output I guess? Same with Kotlin/Java — there's no difference in nullable vs non-nullable types for example. But as long as your codebase is 100% Kotlin, you get proper null safety, and there's no need to fall back to what Java has
- ablob 4y ago
  How are any of the guarantees lost as long as the resulting C++ code isn't touched?
- jcelerier 4y ago
  .. this doesn't make sense at all. If you prove that a program is safe in language A, it doesn't magically become unsafe when transpiled to language B. Every language works by clunking out instruction sets mostly devised in the 1970/80s, this doesn't remove the safety properties of the higher level language.
  - zozbot234 4y ago
    A whole program, yes. A library that's written for language A may well rely on arbitrarily complex preconditions for safety that you may have no hope of establishing within language B. Rust devs get bitten by this all the time when trying to reuse "safe" library code within an unsafe context. (That's one key reason for wanting e.g. Carbon as something that isn't just plain Rust.)
projektfu 4y ago
The static analysis should be able to remain because a lot of the concepts he has implemented here are proposed/implemented for "syntax 1" as well, but they require attributes or specific styles. Therefore, the static analyzer should be written for regular C++23 and will support the defaults of "syntax 2". As far as support in compiled libraries is concerned, that would depend on how those features are implemented in C++23 anyway.
- humanrebar 4y ago
  Well, existing static analysis would break or need to add support for cpp2. In the case of pure cpp2, simpler tools could be written, but they would be new code.
lostdog 4y ago
> Doesn't address other major C++ ecosystem problems like build times, packaging, build systems, etc. cpp2 could make them slightly worse. I assume that as long as the cpp2 syntax is clean, you could improve on compile times. In theory, cpp2 files could compile much more quickly that C++, so as you migrate code to cpp2 your builds speed up? It all depends on how well Sutter has thought through the cpp2 language design I suppose.
- wizofaus 4y ago
  But it's adding an extra compilation step. The only way to will improve compile times is if it avoids the need to recompile all source files referring to header that's only been modified to add/remove/modify private methods/data in a class (even data is an issue if objects of that class are instantiated on the stack). In principle it might be possible for an extra transpilation step to help there if you also take over the "make"-style dependency management. I'm guessing c++ modules is supposed to help address this too?
  - 3836293648 4y ago
    The idea is not adding a compilation step. This is a proof of concept and playground. If it works out it's not going to stay as a transpiler to Cpp1 forever
    - wizofaus 4y ago
      Sure but unless you exclusively use the new syntax (which should be slightly faster to parse, though I'm not sure what % of total compilation time that constitutes) it's still going to have to do at least the same amount of work, if not more (given there's now more that has to be inferred by the compiler, rather than specified explicitly). But from experience the main issue with c++ compliation time is when modifying header files.
- humanrebar 4y ago
  I said that because the user surveys conducted by ISO clearly identify dependency management and build times as the biggest pain points for C++ engineers. Every proposal doesn't have to work on those problems, but other than parsing (i.e., language designer tech) tooling seems like an afterthought in this case. Just like all of the big ideas coming from ISO leadership. Big reasons people look for non-C++ solutions include better build times, dependency management, etc.
einpoklum 4y ago
> Transpiling to C++ means it will work wherever C++ works. Only if you only use this Cpp2 thing. Because the C++ you write may not play nice with the C++ this transpiles into.
- gumby 4y ago
  It support the big 3 (gcc, clang, ms)
  - einpoklum 4y ago
    I didn't mean compiler support, I meant that if the transpilation result might not follow the coding conventions of your C++ codebase.
    - gumby 4y ago
      who cares if it does? It's just an intermediate product from compiling the code with cppfront. gcc and clang both generate assembly files and then call the assembler on them -- I doubt that assembly code matches your coding conventions either.
cpeterso 4y ago
> Transpiling to C++ means it will work wherever C++ works. This approach is similar to Rust's editions. IIUC, nearly all of the differences been editions are compartmentalized in the frontend, deprecating syntax and rewriting old edition code to rustc's current IR.
- tialaramex 4y ago
  Rust's Editions specifically only change the concrete syntax, although there have been hacks to make some stuff that would otherwise be impossible become possible by retrospectively making how things used to work a special case, and of course if some feature needs syntax then you can't use it from an Edition which doesn't have that syntax (e.g. async doesn't exist in Rust 2015 edition) Here's the guide explaining the most significant hack: https://doc.rust-lang.org/edition-guide/rust-2021/IntoIterator-for-arrays.html https://doc.rust-lang.org/edition-guide/rust-2021/IntoIterat... There was a proposal to do Editions for C++, Epochs, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18... but it was not accepted.
  - kibwen 4y ago
    Rust editions can technically change some aspects of the language semantics, but this ability is used sparingly. An example is how the `iter` method on fixed-size arrays changed in the most recent edition. As long as code from all editions can still be used together, a semantic change is possible.
    - tialaramex 4y ago
      > An example is how the `iter` method on fixed-size arrays changed in the most recent edition. Can you explain? The array type doesn't have an iter() method. It will coerce into a slice, which does have an iter() method, but doesn't care whether it's an array we're slicing.
      - kibwen 4y ago
nikki93 4y ago
I've been using my own little Go (subset / my own extensions) -> C++ compiler -- https://github.com/nikki93/gx https://github.com/nikki93/gx -- and found it to be a fun way to add some guardrails and nicer syntax over C++ usage. You get Go's package system and the syntax analyzers / syntax highlighters etc. just work.
titzer 4y ago
Transpilation has historically made source-level debugging more difficult. That's such a huge advantage to have a language that you can actually debug, and this is clearly make it even harder. I feel this is very developer-hostile.
madduci 4y ago
Extra Cons: how do you write in the new syntax when using existing C or C++ libraries? Imagine writing something using OpenSSL, it might look kind of weird or breaking the flow of the new syntax, just because of its legacy.

lbhdc 4y ago

In his talk he demos mixing syntax 1 and 2 (his terms) in the same file. Preprocessor macros work fine unless you enable "pure" mode. He also demos error messages, and was able to get errors from a cpp compiler (msvc) that point to his cpp2 file with a line number and readable error.

mort96 4y ago

This is all true, but I feel it sort of misses the point a bit. The goal seems to be mainly to use cppfront as a test bed for new language syntax and semantics, where most of the ideas will eventually make its way into the C++ standard or into existing compilers. The main reason to use it in production is that it's not meant to be used in production and makes no attempt to be suitable for production use or avoid breaking changes, so the stuff in your cons list doesn't really apply. It's kind of like looking at someone's scale model of a proposed city layout and say that a pro is that tiny plastic houses are cheap to manufacture at scale but a con is that the houses may be too small to live in. But all of your points will become relevant if cppfront eventually gets to a state where it's a serious transpiler meant to be used in production.

kvathupo 4y ago
I agree, and would like to note that there isn't a need to simplify C++ imo. It's folly from a business and productivity standpoint to use one language, especially C++, to do everything from writing web apps to doing exploratory data analysis. Besides, the C++ community seems to overlap with academia by way of its feature updates, reveling in complexity (e.g. "C++20 ranges are totally awesome: memory-safe and performant iterators!").
eslaught 4y ago
I don't think this analogy quite works. If all you wanted to do was evolve the existing C++, then sure, you wouldn't need any of this to be remotely production ready. But to me, part/most of what makes this interesting is the possibility for backwards-incompatible, radical simplifications to the C++ syntax and/or feature set. Those really are only meaningful if they get to a production ready state. And by being backwards-incompatible, they inherently cannot just be bolted onto the existing C++ language spec (as if we wanted to anyway---the spec is far to complex as it is). I will say that it's impressive how much of this has already made it into C++ language specs. But given that Sutter has chosen to release this now, I get the sense that of what remains, large portions cannot continue to simply be done that way.

zozbot234 4y ago

> Transpiling to C++ means it will work wherever C++ works. It also means you don't really benefit from any of the new semantics. Why do all of that static analysis work to establish safety, and then throw the results away by writing out clunky old C++? It all makes very little sense.

zdragnar 4y ago
Transpiling and compiling are turtles all the way down. It's a bit more complicated than, say, typescript to JavaScript, but in spirit is not so very different, right?
wasyl 4y ago
Because you don't actually work with the C++ output I guess? Same with Kotlin/Java — there's no difference in nullable vs non-nullable types for example. But as long as your codebase is 100% Kotlin, you get proper null safety, and there's no need to fall back to what Java has
ablob 4y ago
How are any of the guarantees lost as long as the resulting C++ code isn't touched?
jcelerier 4y ago
.. this doesn't make sense at all. If you prove that a program is safe in language A, it doesn't magically become unsafe when transpiled to language B. Every language works by clunking out instruction sets mostly devised in the 1970/80s, this doesn't remove the safety properties of the higher level language.
- zozbot234 4y ago
  A whole program, yes. A library that's written for language A may well rely on arbitrarily complex preconditions for safety that you may have no hope of establishing within language B. Rust devs get bitten by this all the time when trying to reuse "safe" library code within an unsafe context. (That's one key reason for wanting e.g. Carbon as something that isn't just plain Rust.)

projektfu 4y ago

The static analysis should be able to remain because a lot of the concepts he has implemented here are proposed/implemented for "syntax 1" as well, but they require attributes or specific styles. Therefore, the static analyzer should be written for regular C++23 and will support the defaults of "syntax 2". As far as support in compiled libraries is concerned, that would depend on how those features are implemented in C++23 anyway.

humanrebar 4y ago
Well, existing static analysis would break or need to add support for cpp2. In the case of pure cpp2, simpler tools could be written, but they would be new code.

lostdog 4y ago

> Doesn't address other major C++ ecosystem problems like build times, packaging, build systems, etc. cpp2 could make them slightly worse. I assume that as long as the cpp2 syntax is clean, you could improve on compile times. In theory, cpp2 files could compile much more quickly that C++, so as you migrate code to cpp2 your builds speed up? It all depends on how well Sutter has thought through the cpp2 language design I suppose.

wizofaus 4y ago
But it's adding an extra compilation step. The only way to will improve compile times is if it avoids the need to recompile all source files referring to header that's only been modified to add/remove/modify private methods/data in a class (even data is an issue if objects of that class are instantiated on the stack). In principle it might be possible for an extra transpilation step to help there if you also take over the "make"-style dependency management. I'm guessing c++ modules is supposed to help address this too?
- 3836293648 4y ago
  The idea is not adding a compilation step. This is a proof of concept and playground. If it works out it's not going to stay as a transpiler to Cpp1 forever
  - wizofaus 4y ago
    Sure but unless you exclusively use the new syntax (which should be slightly faster to parse, though I'm not sure what % of total compilation time that constitutes) it's still going to have to do at least the same amount of work, if not more (given there's now more that has to be inferred by the compiler, rather than specified explicitly). But from experience the main issue with c++ compliation time is when modifying header files.
humanrebar 4y ago
I said that because the user surveys conducted by ISO clearly identify dependency management and build times as the biggest pain points for C++ engineers. Every proposal doesn't have to work on those problems, but other than parsing (i.e., language designer tech) tooling seems like an afterthought in this case. Just like all of the big ideas coming from ISO leadership. Big reasons people look for non-C++ solutions include better build times, dependency management, etc.

einpoklum 4y ago

> Transpiling to C++ means it will work wherever C++ works. Only if you only use this Cpp2 thing. Because the C++ you write may not play nice with the C++ this transpiles into.

gumby 4y ago
It support the big 3 (gcc, clang, ms)
- einpoklum 4y ago
  I didn't mean compiler support, I meant that if the transpilation result might not follow the coding conventions of your C++ codebase.
  - gumby 4y ago
    who cares if it does? It's just an intermediate product from compiling the code with cppfront. gcc and clang both generate assembly files and then call the assembler on them -- I doubt that assembly code matches your coding conventions either.

cpeterso 4y ago

> Transpiling to C++ means it will work wherever C++ works. This approach is similar to Rust's editions. IIUC, nearly all of the differences been editions are compartmentalized in the frontend, deprecating syntax and rewriting old edition code to rustc's current IR.

tialaramex 4y ago
Rust's Editions specifically only change the concrete syntax, although there have been hacks to make some stuff that would otherwise be impossible become possible by retrospectively making how things used to work a special case, and of course if some feature needs syntax then you can't use it from an Edition which doesn't have that syntax (e.g. async doesn't exist in Rust 2015 edition) Here's the guide explaining the most significant hack: https://doc.rust-lang.org/edition-guide/rust-2021/IntoIterator-for-arrays.html https://doc.rust-lang.org/edition-guide/rust-2021/IntoIterat... There was a proposal to do Editions for C++, Epochs, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18... but it was not accepted.
- kibwen 4y ago
  Rust editions can technically change some aspects of the language semantics, but this ability is used sparingly. An example is how the `iter` method on fixed-size arrays changed in the most recent edition. As long as code from all editions can still be used together, a semantic change is possible.
  - tialaramex 4y ago
    > An example is how the `iter` method on fixed-size arrays changed in the most recent edition. Can you explain? The array type doesn't have an iter() method. It will coerce into a slice, which does have an iter() method, but doesn't care whether it's an array we're slicing.
    - kibwen 4y ago

nikki93 4y ago

I've been using my own little Go (subset / my own extensions) -> C++ compiler -- https://github.com/nikki93/gx https://github.com/nikki93/gx -- and found it to be a fun way to add some guardrails and nicer syntax over C++ usage. You get Go's package system and the syntax analyzers / syntax highlighters etc. just work.

titzer 4y ago

Transpilation has historically made source-level debugging more difficult. That's such a huge advantage to have a language that you can actually debug, and this is clearly make it even harder. I feel this is very developer-hostile.

madduci 4y ago

Extra Cons: how do you write in the new syntax when using existing C or C++ libraries? Imagine writing something using OpenSSL, it might look kind of weird or breaking the flow of the new syntax, just because of its legacy.