Awesome!

• Dealing with the "declared and not used" errors from cases where one return value of bits.Mul64 is unused (the other is used), etc. (@FiloSottile thoughts?)

If you know already that you won't use that value, just call it _ and it will get ignored. Otherwise you have to explicitly ignore it by doing something like _ = a.

• Figuring out what's up with remaining Z.combine_at_bitwidth in 32-bit outputs (maybe not necessary if Go only cares about cases when we have 64 bit integers available?) (@FiloSottile can we use uint64 on 32-bit platforms?)

We can use uint64 on 32-bit platforms, but it might not have acceptable performance?

If you know already that you won't use that value, just call it _ and it will get ignored. Otherwise you have to explicitly ignore it by doing something like _ = a.

This is pretty tricky for us. I could make it happen, but it'd probably take a week or two of my working on it full time. Within each function, though, we don't reuse variable names. Could you get a post-processing phase to do this?

We can use uint64 on 32-bit platforms, but it might not have acceptable performance?

Nah, should be fine, we'd only use it to get 32x32 -> 32x32 multiplication, and also for 32-bit add-with-carry.

If you know already that you won't use that value, just call it _ and it will get ignored. Otherwise you have to explicitly ignore it by doing something like _ = a.

This is pretty tricky for us. I could make it happen, but it'd probably take a week or two of my working on it full time. Within each function, though, we don't reuse variable names. Could you get a post-processing phase to do this?

Yeah, sounds like it will be easier to do in post-processing.

@FiloSottile Success! All of the Go files now build!

Btw, I added in a post-processing phase that replaces unused identifiers with _, so you don't have to. (There aren't any proofs about this pass, just like there aren't any proofs about any of the stringification bits.)

I am going to merge this. @FiloSottile feel free to open an issue if you want changes to this, or want this published as a Go package like the Rust code is, or whatever.