What's the purpose of this branch btw? Looks like if radix can be derived statically, we'd get a little less code, while if it can't, we'd get double the code.

The main diff is 10 radix uses extract_lane_s while rest of radixes use extract_lane_u

Ah, I see. Feels a little inconsistent, though. Is this behavior based on a particular assumption? From Binaryen or so?

In this case it is a rather temporary solution, because we have no separated types like i8x16, u32x4 and all these types are associated with a general v128 proto. So to get something like pretty printing for the standard radix = 10 I use the signed version abut for radix = 16 and others - unsigned, which is usually expected.

Perhaps conceptionally a v128 is similar to an ArrayBuffer containing fixed length untyped data. ArrayBuffer's toString is just [object ArrayBuffer] but it has views like Uint8Array to make sense of the values separately, while v128 currently has no such views. If we'd want to align with JS's precedent (in the future), an untyped 128-bit vector's toString could be [v128] while a future i8x16 could yield 0,127,-1,... like an Int8Array. Conservatively, it might make sense to be careful about v128's toString then, since changing it again is, for those who begin to rely on the temporary solution, a breaking change. As such I'd kinda prefer a conservative solution like [v128] I think, hmm. Wdyt?

The basic idea is print i8x16(0, -127, ...).toString() as 0 -127 ... and i8x16(0, -127, ...).toString(16) as 0x00 0x81 ... instead 0x00 -0x7f .... But I'm ok if we always will print values as signed values

If there'd only be i8x16 that would probably be ok I guess, but it doesn't work so well for other types, say i32x4(0, 255, ...).toString() is quite surprising. To avoid backwards incompatible changes, an approach could be:

1. Add a V128#toString here but make it independent of the representation, say returning [v128] so we won't have to change it again in the future.
2. Add i8x16, i32x4 etc. types later which implement their own #toString doing the correct thing, say modeled after Int8Array#toString. Make the new types implicitly castable to and from v128.

My primary concern is the backwards incompatibility aspect that seems to result from being too eager to early, and that it is avoidable.

I prefer point 2. But it required significant efforts, which is out of scope of current PR.

Right, hence suggesting to do 1. here and 2. later to be safe.

So this PR already add V128#toString