Should v8x16.shuffle be i8x16.shuffle?

[tlively]

The v8x16.shuffle name correctly avoids interpreting the lanes as integers, but it is the only instruction using this style of vector type naming, so it can be confusing and surprising to the reader (e.g. me). There are also no interpretations of an 8-bit lane other than i8, so avoiding lane interpretation in the name seems unnecessary. I therefore propose changing v8x16.shuffle to i8x16.shuffle based on the principle of least astonishment.

[sunfishcode]

To me the surprising thing is the choice to use a single shuffle that's independent of lane size or element type, because that's different from most other SIMD abstraction layers. But with that design, the name v8x16.shuffle seems natural. It's not an 'i' integer operation, because this is the way one shuffles floating-point operators too. So it's similar to names like v128.const.

[tlively]

I wonder if v128.shuffle would make more sense, then. As you mentioned, this instruction is currently the only way to shuffle vectors of any type, and the "v128" prefix strikes me as a good choice for instructions that operate on full vectors without interpreting lane boundaries or contents. I don't feel too strongly about this, though. The "v8x16" name was just surprising to me when I first saw it.

[arunetm]

v8x16.shuffle was preserved as its functionality subsumed all other shuffles. It makes sense to preserve the v128.shuffle naming for the reasons pointed out above.