[jjnoakes]

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?

[pcwalton]

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]

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]

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]

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

[solidsnack9000]

Although I don't agree with this poster, it seems odd that they're being downvoted.

[valarauca1]

>>>yes, C and C++ are more portable than LLVM

C and C++ are more portable then their own compiler's backend? LLVM is clang/clang++'s assembler

I get what your saying if you compile to C it can be more portable. But then you need to compile to some C standard.

K&R C? ANSI C? C90? C99? C11? Why not have a compiler flag for each? What about embedded C? What companies embedded C?

I can repeat this for C++

Compiling to C/C++ in a platform and standard agnostic way is impossible.

[jjnoakes]

Lots of languages do it already. How is it impossible?

[valarauca1]

No.

Lots of languages can give you a dump in 1 standard of C. You can't specify what C standard, or what platform to output outside of ARM/x64. NIM, Cython, C++ (via clang), [Ada/Cobalt/Fortran]-GCC, Perl, Agol, Oracle PL/SQL only support x86_64 and ARM.

Your argument was

    interoperability and portability

1) Rust outputs to the same object file format as C, and can be natively linked against C/C++ code. So interoperability is no issue.

2) You have no portability gain as you have 3 choices x86, x64, and ARM. All of which Rust already supports.

Also your main request

    $ rustc your_program.rs --emit llvm-ir
    $ llc -march=c -o your_program.c your_program.ll

or if you want C++

    $ rustc your_program.rs --emit llvm-ir
    $ llc -march=cpp -o your_program.cpp your_program.ll

[jjnoakes]

Who needs more than one dialect of C or C++? I don't. Any systems I'm interested in may not support clang, but they have C11 compilers and C++14 compilers.

Rust is not interoperable with C++ as far as I know, and even if it was, I'm not interested in Rust for this discussion for reasons I've mentioned elsewhere.

The LLVM C backend was removed. Julia devs have a version that supports the LLVM bit code that they require, but I believe it is not everything LLVM can produce.

I was under the impression that march=cpp output C++ code that rebuilt the IR, not implemented the source program.

Thanks for the advice, although none of it really applies to what I'm suggesting.

[posterboy]

> Please don't tell others what not to do.

kind of paradox to say that

[jjnoakes]

Is it?

Mine was worded as a polite request and his was worded as a command.

[hellofunk]

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]

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]

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]

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?

[jjnoakes]

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?

[froydnj]

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]

:) I'm glad others enjoy doing it. Definitely one of the things I like about Rust at this point is the freshness.

[tomne]

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]

It's not about want, it's about a requirement that they're maintained, expanded.

[bluejekyll]

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.

[pix64]

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]

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]

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]

Yes, that's exactly what I proposed.

[lfowles]

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