Can’t it be compiled as a struct of a normal pointer and an “index” to a field/offset whatever? Not the most efficient, but with value types it might not be too bad.
That's what 4ad meant by "something ugly like fat pointers".
The overhead compared with interior pointers is relatively high due to the extra space for the fat pointer index, which space is taken everywhere a pointer could be an interior pointer, even if it's rare.
When a language runtime can optimise in whatever way it needs to, if interior pointers aren't an option there are various schemes to avoid the fat pointer space overhead and replace it with time overhead, but they often involve using unused bits in the pointer word, or recognise certain address ranges. Unfortunately, I assume those techniques are incompatible with a GC like WasmGC's, which requires all pointers to use the standard pointer representation, so prevents these kinds of space and time optimisations.
Probably, but it means all pointers need that representation because any pointer could be an interior pointer. If you’re given an arbitrary pointer, it could point somewhere within any object. (Unless it can be proven otherwise using escape analysis.)
Whether a pointer is an interior pointer or not isn’t part of its type in Go.
