5 ms·

Is there any demand for a syntactic sugar layer on top of C++? Something to make these new features more ergonomic? Something one could opt-in to for newer code

Is there any demand for a syntactic sugar layer on top of C++? Something to make these new features more ergonomic? Something one could opt-in to for newer code, or code that doesn't need to be backward compatible to 1990? Something that outputs valid C++ and so works with any tool chain?

lfowles 10y ago
Well we did get `for (auto x : range)` not long ago!
hellofunk 10y ago
Lot of syntactic sugar recently added to C++ and a lot more in C++17. The structured bindings in particular are really excellent ways for unpacking tuples and structs with type inference into new variables automatically.
- jjnoakes 10y ago
  Yeah but if you read the article and look at the syntax for C++ match-like statements, it leaves a lot to be desired.
  - hellofunk 10y ago
    For pattern matching, that's true. And my response is, stay tuned. C++ has a lot more to offer in this area in the future. std::variant is opening a big door for all kinds of new features in the language, and for those who cannot wait, there are pattern matching libraries out there to peak at.
    - bluejekyll 10y ago
      I feel like this point is often made about C++: "in the future we will have that feature too!" If you don't want to wait, want to experiment with something else, learn a new language, etc., Rust is awesome. Obviously the counter argument to this is, "but there's 30+ years of C++ in production", but be honest, who actually wants to work on a 30 year old codebase?
      - froydnj 10y ago
        GCC is very close to the 30-year mark (0.9 released 22 March 1987). Linux turned 25 this past year; Firefox (the C++ parts, at least) is very close to 25, depending on what code you want to count. Apache is 20ish years old. Even LLVM, which I think of as a relatively young project, is getting close to 15 years. Maybe (hopefully?) very little code survives from the initial versions, but they've all withstood the test of time. It's certainly pleasing to be able to sit down and write something from scratch or nearly from scratch. But it can be equally pleasing to extend a multi-million line codebase to do something new, or to enable the codebase as a whole to do something new/better.
        bluejekyll 10y ago
        :) I'm glad others enjoy doing it. Definitely one of the things I like about Rust at this point is the freshness.
        tomne 10y ago
        The one thing I like about Rust is the fact that you can easily expose a C-like interface for libraries, which allows you to contribute to old codebases without much of a problem, best of both worlds (It has a non-trivial cost when starting, sure, but so does keeping C++).
      - clappski 10y ago
        It's not about want, it's about a requirement that they're maintained, expanded.
        bluejekyll 10y ago
        Yes, and perhaps I'm shirking my duty as a developer by wanting to avoid some ugly gnarly code. I will say this, I would be more likely to want to contribute to projects like these if they incorporated Rust as an alternative to C or C++ for their development.
      - jjnoakes 10y ago
        That's why I made my proposal above. What if you could have the nice syntax now (via translation to c++ source) instead of waiting for the future? Why do I have to wait for every compiler on every system I want to build on to update to some future standard when things could be done now across the board in many cases?
pcwalton 10y ago
That would be a compiler for a language to C/C++. That design decision is virtually always a bad idea: LLVM has simpler semantics, allows proper GC, allows proper debug info, is widely portable, and avoids a needless AST serialization/deserialization step. Don't compile to C.
- jjnoakes 10y ago
  Please don't tell others what not to do. First, there are cases where compiling other languages to C or C++ is better than via LLVM; interoperability and portability are two (yes, C and C++ are more portable than LLVM). Second, I'm not really talking about compiling some wildly different language to C++. I'm talking about some simple syntactic sugar. The same syntactic sugar that would be in an existing C or C++ compiler's front end, except instead of adding it to all the frontends in the world and waiting years, I'd like to implement it just once and now.
  - pcwalton 10y ago
    Effort in this direction would be better spent just adding new features to clang (or GCC). It'll be so much easier than writing a new parser and semantic analysis for C++, which you will have to do if you want the new feature to behave properly in the presence of templates, etc. You'll end up wanting to just use clang's front end to help you, like most C++ tools do—and at that point why not just modify clang itself? People bring up obscure platforms (though, interestingly, I can't recall anybody actually naming one of those platforms) all the time as motivation for compiling to C. But if you really need to do that, you can always revive the LLVM C backend. The fact that nobody has bothered to revive it and keep it up to date enough to be merged into LLVM proper, to me, is a strong indication that few people need support for these obscure platforms.
    - jjnoakes 10y ago
      > Effort in this direction would be better spent just adding new features to clang (or GCC). In your opinion. This isn't a fact. For example, I know first hand of code that has to compile with compilers that are not in the set { gcc, clang, msvc }. What do I do then? (Oh, and those compilers are closed-source). > You'll end up wanting to just use clang's front end to help you Probably, although there are other options too > and at that point why not just modify clang itself? The changes I make, if useful to the community, would probably end up back in clang. But they would also remain a separate tool, because of all those other pesky compilers I work with. > you can always revive the LLVM C backend I'm not sure how that helps me; not only does it seem a terribly roundabout way to get what I'm looking for (instead of sugar -> c++ -> my c++ compiler, you are proposing sugar -> clang -> llvm -> c -> my c compiler), but I don't think objects produced by that pipeline would link with C++ objects produced from my native compilers, among other issues. > The fact that nobody has bothered to revive it and keep it up to date enough to be merged into LLVM proper, to me, is a strong indication that few people need support for these obscure platforms. Or, is it evidence that people using more obscure platforms (we're talking fortune 500 companies here) stick to languages that exist on their platforms for various reasons?
pix64 10y ago
I think at that point you're creating a new language or at least a new (incompatible) version of the language. In this case, why limit yourself to C++ at all?
- jjnoakes 10y ago
  I don't see the distinction you are suggesting. Call it a new language if you like, but if it compiles to C++, looks 99% like C++, and just smooths over the warts, then whatever you call it, that's what I'm suggesting. (I want it to compile to C++ so I can use the compilers I use and it can interoperate with the C++ code it has to interoperate with and C++ programmers that work on this code wouldn't have to learn more than a few extras that might make their lives easier).
  - nambit 10y ago
    You're looking for some sort of code generator for C++ which only adds syntactic sugar? Interesting idea but I don't think a good one exists yet.
    - jjnoakes 10y ago
      Yes, that's exactly what I proposed.

lfowles 10y ago

Well we did get `for (auto x : range)` not long ago!

hellofunk 10y ago

Lot of syntactic sugar recently added to C++ and a lot more in C++17. The structured bindings in particular are really excellent ways for unpacking tuples and structs with type inference into new variables automatically.

jjnoakes 10y ago
Yeah but if you read the article and look at the syntax for C++ match-like statements, it leaves a lot to be desired.
- hellofunk 10y ago
  For pattern matching, that's true. And my response is, stay tuned. C++ has a lot more to offer in this area in the future. std::variant is opening a big door for all kinds of new features in the language, and for those who cannot wait, there are pattern matching libraries out there to peak at.
  - bluejekyll 10y ago
    I feel like this point is often made about C++: "in the future we will have that feature too!" If you don't want to wait, want to experiment with something else, learn a new language, etc., Rust is awesome. Obviously the counter argument to this is, "but there's 30+ years of C++ in production", but be honest, who actually wants to work on a 30 year old codebase?
    - froydnj 10y ago
      GCC is very close to the 30-year mark (0.9 released 22 March 1987). Linux turned 25 this past year; Firefox (the C++ parts, at least) is very close to 25, depending on what code you want to count. Apache is 20ish years old. Even LLVM, which I think of as a relatively young project, is getting close to 15 years. Maybe (hopefully?) very little code survives from the initial versions, but they've all withstood the test of time. It's certainly pleasing to be able to sit down and write something from scratch or nearly from scratch. But it can be equally pleasing to extend a multi-million line codebase to do something new, or to enable the codebase as a whole to do something new/better.
      - bluejekyll 10y ago
        :) I'm glad others enjoy doing it. Definitely one of the things I like about Rust at this point is the freshness.
      - tomne 10y ago
        The one thing I like about Rust is the fact that you can easily expose a C-like interface for libraries, which allows you to contribute to old codebases without much of a problem, best of both worlds (It has a non-trivial cost when starting, sure, but so does keeping C++).
    - clappski 10y ago
      It's not about want, it's about a requirement that they're maintained, expanded.
      - bluejekyll 10y ago
        Yes, and perhaps I'm shirking my duty as a developer by wanting to avoid some ugly gnarly code. I will say this, I would be more likely to want to contribute to projects like these if they incorporated Rust as an alternative to C or C++ for their development.
    - jjnoakes 10y ago
      That's why I made my proposal above. What if you could have the nice syntax now (via translation to c++ source) instead of waiting for the future? Why do I have to wait for every compiler on every system I want to build on to update to some future standard when things could be done now across the board in many cases?

pcwalton 10y ago

That would be a compiler for a language to C/C++. That design decision is virtually always a bad idea: LLVM has simpler semantics, allows proper GC, allows proper debug info, is widely portable, and avoids a needless AST serialization/deserialization step. Don't compile to C.

jjnoakes 10y ago
Please don't tell others what not to do. First, there are cases where compiling other languages to C or C++ is better than via LLVM; interoperability and portability are two (yes, C and C++ are more portable than LLVM). Second, I'm not really talking about compiling some wildly different language to C++. I'm talking about some simple syntactic sugar. The same syntactic sugar that would be in an existing C or C++ compiler's front end, except instead of adding it to all the frontends in the world and waiting years, I'd like to implement it just once and now.
- pcwalton 10y ago
  Effort in this direction would be better spent just adding new features to clang (or GCC). It'll be so much easier than writing a new parser and semantic analysis for C++, which you will have to do if you want the new feature to behave properly in the presence of templates, etc. You'll end up wanting to just use clang's front end to help you, like most C++ tools do—and at that point why not just modify clang itself? People bring up obscure platforms (though, interestingly, I can't recall anybody actually naming one of those platforms) all the time as motivation for compiling to C. But if you really need to do that, you can always revive the LLVM C backend. The fact that nobody has bothered to revive it and keep it up to date enough to be merged into LLVM proper, to me, is a strong indication that few people need support for these obscure platforms.
  - jjnoakes 10y ago
    > Effort in this direction would be better spent just adding new features to clang (or GCC). In your opinion. This isn't a fact. For example, I know first hand of code that has to compile with compilers that are not in the set { gcc, clang, msvc }. What do I do then? (Oh, and those compilers are closed-source). > You'll end up wanting to just use clang's front end to help you Probably, although there are other options too > and at that point why not just modify clang itself? The changes I make, if useful to the community, would probably end up back in clang. But they would also remain a separate tool, because of all those other pesky compilers I work with. > you can always revive the LLVM C backend I'm not sure how that helps me; not only does it seem a terribly roundabout way to get what I'm looking for (instead of sugar -> c++ -> my c++ compiler, you are proposing sugar -> clang -> llvm -> c -> my c compiler), but I don't think objects produced by that pipeline would link with C++ objects produced from my native compilers, among other issues. > The fact that nobody has bothered to revive it and keep it up to date enough to be merged into LLVM proper, to me, is a strong indication that few people need support for these obscure platforms. Or, is it evidence that people using more obscure platforms (we're talking fortune 500 companies here) stick to languages that exist on their platforms for various reasons?

pix64 10y ago

I think at that point you're creating a new language or at least a new (incompatible) version of the language. In this case, why limit yourself to C++ at all?

jjnoakes 10y ago
I don't see the distinction you are suggesting. Call it a new language if you like, but if it compiles to C++, looks 99% like C++, and just smooths over the warts, then whatever you call it, that's what I'm suggesting. (I want it to compile to C++ so I can use the compilers I use and it can interoperate with the C++ code it has to interoperate with and C++ programmers that work on this code wouldn't have to learn more than a few extras that might make their lives easier).
- nambit 10y ago
  You're looking for some sort of code generator for C++ which only adds syntactic sugar? Interesting idea but I don't think a good one exists yet.
  - jjnoakes 10y ago
    Yes, that's exactly what I proposed.