Maybe switch to using views instead of arrays?

If we were to implement my suggestion for supporting all numeric array types, I thought it could be useful to introduce a new view heap type that could represent untyped binary data, and make the load/store instructions work on view types instead of array types.

To facilitate this, a new instruction along the lines of view.convert_array would need to be added, which converts a numeric array type to a view. The view type would be an immediate subtype of eq and a sibling type to array. There would be both mutable and immutable views, depending on the mutability of the array they were converted from. The view would point to the same underlying memory as the array type it was converted from, and the conversion should be done in constant time.

I feel this has several advantages compared to working with arrays directly:

1. If my suggestion for supporting all numeric array types were to be implemented, code may need to branch depending on the array type to use the instruction with the correct immediate type, even though the underlying logic and semantics are the same.
2. This would make the binary format simpler, because instead of having a type immediate in the instruction, we could simply reserve another bit in memarg to denote whether the view is mutable or not. This might turn out to not even be necessary, because the semantics could allow for load instructions to work on both mutable and immutable views, and stores would only work on mutable views.
3. This would also resolve the question regarding 8-bit accesses, because since we would no longer be working with arrays, they would be needed anyway.
4. While not strictly necessary for this proposal, we could add another instruction like array.convert_view, which would complete the loop and effectively allow reinterpret-casting of numeric arrays, e.g. (array (mut f32)) -> (view (mut)) -> (array (mut i32)). This is not currently possible, as the gc proposal does not allow for casting between any two array types. Note that this would not replace the functionality of this proposal: array indexing only supports aligned loads and stores, while this proposal supports unaligned accesses, as well as SIMD load/store instructions with more complicated semantics, e.g. v128.store8_lane, v128.load32x2_u, v128.load16_splat, etc.

If it turns out that adding a new view heap type would be too complicated or would slow down this proposal, we could alternatively continue using the (array i8) and (array (mut i8)) types, and I think most of the advantages I described above would still apply.

Let me know what you think about this @brendandahl.

Start by reading issues #3 and #2, then compare the proposed view heap type and view.convert_array approach with the alternative of using array i8 types. Done requires a decided design for view mutability, conversion semantics, load/store typing, and whether array.convert_view is in scope.