Ross Tate

Field Accessors solved multiple problems. One of those problems can be addressed by adding more instructions in the future. But another problem cannot be fixed by adding instructions. This change...

> I'd assume that that, too, can be avoided with new instructions: the old instructions could simply not validate with types that have multiple upper bounds. Unfortunately your suggestion is...

So WebAssembly has the subsumption rule/property that implies that if an instruction type-checks with `ref A` on the (input) stack, then it also type-checks with `ref B` on the (input)...

Oh, I forgot about keeping the structural stuff around. In that case, the change would be to require that the `u32` immediate for `_extending` type definitions must refer to either...

> Another thing that's becoming clear from these discussions is that struct.get and struct.new_with_rtt fall into slightly different categories. IIUC, @RossTate's concerns only apply to the former; so one way...

Sure thing, but can you first confirm that you are asking for a Post-MVP application where support for the described situation (i.e. support for type variables/imports with multiple upper bounds)...

> I would appreciate a taste of how these problems might come up. Happy to oblige. There are two use cases that I know of. The first is multiple upper...

I'm confused. I said it's fine to not ever have any annotation on `struct.get` so long as we slightly change how types are defined. That is, the (future) accompanying change...

Ah. That way could either be have an annotation (to prevent ambiguities when there would otherwise be multiple incomparable applicable concrete types) *or* impose some more structure (such as hierarchies)...

> We can productively discuss how to maintain principal types in the presence of multiple bounds when we add the latter. There is more than one way that can be...