[mercurial]

IMO, rustc_codegen_gcc is much more reasonable in scope. It also stands a chance of actually keeping up with subsequent Rust releases. I would be surprised if gcc-rs ever achieved any traction. Not to say it's not a fun project, but I can't see it replicating rustc.

[e3bc54b2]

It doesn't has to match rustc on nightly, only the 3-yearly releases. That seems doable, considering Rust has slowed down a bit, compared to super fast pace of change in early years. Regardless, it is always good to have alternate implementations, C++ has only benefited from it.

[tialaramex]

I'm guessing you aren't a Rust programmer?

By "3-year releases" you're probably meaning Editions, but Rust Editions aren't like the C++ Standard, where they're bundling together a bunch of new features† the Edition changes language syntax, usually in small ways. The features people care about are released every six weeks and aren't saved up for new Editions.

For example, 1.69 released last week, so now: SocketAddr::new(IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)), 8080)

... is a constant, at compile time the data structure equivalent to 127.0.0.1:8080 is constructed and baked into your binary program.

If I write a Rust program which relies on this for a constant, it works fine, because it is constant, but if I try to compile it with Rust 1.68 (from earlier this year) it won't work. If an alternative compiler doesn't have the features of Rust 1.69, then code written for Rust 1.69 won't necessarily work with it. Sometimes such differences will be tiny, other times huge.

† And notice that just because say, Modules was a C++ 20 feature, did not mean that you woke up one day in 2020 and had working Modules, C++ 20 is just an ISO document, the features have to get implemented by vendors, and then tested, and then shipped, which can take weeks, or months, or years.