Compiling Rust with GCC: an update

Posted Sep 13, 2022 11:19 UTC (Tue) by milesrout (subscriber, #126894)
In reply to: Compiling Rust with GCC: an update by moltonel
Parent article: Compiling Rust with GCC: an update

What's the point of multiple implementations if it's insisted that they all operate completely in lockstep, a few versions behind rustc? What's the point of multiple implementations if the "rustc" version is considered the same thing as the Rust version?

The best thing about having a separate Rust implementation would be that long-needed features could be implemented and used that have been languishing in RFCs for years being bikeshedded to death. How long did it take for const generics to be added? And they're still highly limited. Where are generic associated types? Tracking issue open for FIVE YEARS. Where are DST coercions? The DST coercion tracking issue has been open for SEVEN YEARS, almost as long as Rust has existed, and they're going nowhere.

to post comments

Compiling Rust with GCC: an update

Posted Oct 1, 2022 12:44 UTC (Sat) by sammythesnake (guest, #17693) [Link] (1 responses)

That sounds like a very risky prospect to me.

If those bikeshedded features do eventually escape the shed and appear in rust (as defined by rustic or by some future official spec) they may not do so unchanged from whatever variant was implemented in whatever codebase jumped the gun. Then what we have is two implementations that are incompatible and codebases designed for each one.

At the very least, it would be necessary to have some way to indicate (analogously with editions?) which version of which features are implemented (e.g. rust 1.55 + shiny-new-feature-1-from-draft-spec-NNNN-x.yy.zzz + shiny-new-feature-2-from-draft-spec-MMMM-a.bb.ccc + ...) that code could indicate it's coded for.

To be able to compile such code, rustc (or any third implementation) would also have to provide compatible support for these incompatible variants. Variants that they explicitly declined to implement pending conclusion of bikeshedding.

I suppose they could be handled similarly to unstable features, though.

If the additions were limited to adding selected features from a future edition (e.g. rust 1.55 + feature-AAAA-from-rust-1.56) then you could reasonably hope that the more involved edition-plus-modifiers thing might at least be *forward* compatible, but still horribly convoluted and developers would likely much prefer to keep the number of modifiers specified to a minimum by simply upping the edition they specify at the first opportunity.

In a worse scenario, though, the features caught in bikeshed limbo might be decisively NACKed leaving two permanently diverged forks of the language. That can't possibly be a good thing.

Perhaps lessons can be learned from "browser feature detection" in various JavaScript libraries which has been a thing for quite some time. Is it reliably non-nightmarish...?

Compiling Rust with GCC: an update

Posted Oct 1, 2022 14:05 UTC (Sat) by Wol (subscriber, #4433) [Link]

I think anything like that is promptly going to fall foul of different people running different rustc.

If there are two major compilers, stuff will be NACK'd if it doesn't run on both. And even if it's bikeshedded over, the "editions" stuff will make sure it's okay.

(And from the efforts the rust people are going to for linux, and also given Linus' very pragmatic not purist attitude, stuff that linux wants is not likely to suffer too much bikeshedding. Even if it does (quite likely) end up as "this only exists in unsafe code".)

Cheers,
Wol