Rewriting from C to C++ and/or Rust

[Rangi42]

@ISSOtm has an ongoing personal project rsgbds, which is eventually intended to rewrite RGBDS in Rust (motivation: memory safety via borrow checker, error reporting, better dev experience overall, more popular for new contributors). Currently it's focused on rewriting RGBASM.

@Rangi42 eventually intends to convert the existing RGBDS codebase from C to C++ (advantages: memory safety via smart pointers, generic containers, strings), starting with the minimal changes (#1176) need for it to compile as C++ at all. (RGBGFX was already rewritten in C++.)

The plan is for both of these efforts to go on in parallel. Design decisions made by one may be relevant to improving the other. This discussion is for coordinating any such design ideas.

[ISSOtm]

rsgbds

My intent with rsgbds is to eventually upstream it, replacing the current C/C++ codebase once it reaches parity. (My understanding is that Rangi was okay with this?)

"Parity" means, to me, no user-facing breaking changes; the change of implementation language should not cause more headaches for downstream than any other incremental update.

I'm aware this is merely wishful thinking for downstream packagers, but what they would prefer is that we don't change underlying tech at all, so someone has to give 😛

In practice, this means supporting the same distributables that we already do; the static macOS binaries will be the most sensitive, but we can probably figure that out later.

[ISSOtm]

That much is unclear, especially as anything added to the C codebase will eventually be duplicated effort; thus, I think it would be preferable to focus our efforts on the port after the 0.7.0 release (and on fixing any bugs in a 0.7.1, should anything significant be found).

[ISSOtm]

To be clear: I do not intend to add any language features in the process of porting.

There are some improvements like the better error reporting, as I felt that it would be a better idea to integrate it from the get-go, and it's not something we already cover under our backwards compat guarantees.

[Rangi42]

Hmm, okay. I'm already clearing out the low-hanging fruit re: feature requests in 0.7.0. I'd like to at least get std::vector in for it as well. After that's released and known bug-free, yeah, I can move effort to the Rust rewrite.

[ISSOtm]

Any structural changes to the codebase do not affect the port; only features need to be chased.

I will also keep reviewing and accepting changes, just with reduced bandwidth.

[ISSOtm]

To be clear: I do not intend to add any language features in the process of porting.

One exception is longer string literals and symbol names. I think sticking to perfect parity on that is not worth the effort, and also that the change is inconsequential.

Perhaps a good criterion would be that the manual should apply unchanged, but anything beyond that is fair game to tweak?

[Rangi42]

The C-to-C++ port has been finished since 0.8.0, and we have a clear goal for the Rust rewrite (initially no new features, just match the existing rgbasm(5) manual).