Skip to content
This repository was archived by the owner on Apr 25, 2025. It is now read-only.

Relationship between all the heap types #131

Closed
dcodeIO opened this issue Sep 1, 2020 · 4 comments
Closed

Relationship between all the heap types #131

dcodeIO opened this issue Sep 1, 2020 · 4 comments

Comments

@dcodeIO
Copy link

dcodeIO commented Sep 1, 2020

With reference types, function references, exceptions and GC there are multiple proposals in flight currently that introduce or concretise heap types, and I'd like to understand the relationship the new types will have in the whole picture.

There are the extern and func heap types coming from reference types, and the exn heap type from exception handling. GC introduces any, eq and i31 on top, establishing the following subtyping relationship:

        any
   ┌─────┼────┬─────┐
extern  func  eq   exn
         │    │
   signature* │
              │
        ┌─────┼────────┐
       i31  struct*  array*

with

  • signature* being a concrete function
  • struct* being a concrete struct
  • array* being a concrete array

What I am not sure about is:

  • Is extern a subtype of eq?
  • Are there subtypes of extern?
  • Is exn a subtype of eq?

Or is there perhaps something fundamentally wrong in my understanding?

@jakobkummerow
Copy link
Contributor

The graph you've drawn matches my understanding.

externref is the new name for what used to be called anyref, and back then intentionally didn't support equality checking, so I'd assume that it continues to not be a subtype of eqref. I further assume that it won't have any subtypes, because by virtue of being an "external" reference, it's opaque to Wasm. (That said, it's conceivable that we may want to allow subtype hierarchies of opaque external references; AFAIK no such proposal is in flight yet; and the use case might be subsumed by the type-imports proposal.)

My understanding is that the exceptions proposal is debating changes that would drop the exnref type.

And you're probably aware that within this GC proposal, there's some debate around i31, so that might change in the future as well.

@bvibber
Copy link

bvibber commented Sep 2, 2020

externref is the new name for what used to be called anyref, and back then intentionally didn't support equality checking, so I'd assume that it continues to not be a subtype of eqref. I further assume that it won't have any subtypes, because by virtue of being an "external" reference, it's opaque to Wasm. (That said, it's conceivable that we may want to allow subtype hierarchies of opaque external references; AFAIK no such proposal is in flight yet; and the use case might be subsumed by the type-imports proposal.)

Does this mean that GC will no longer have an anyref type? Or that GC's anyref type is different from the anyref-now-externref previously mentioned in reference types?

@binji
Copy link
Member

binji commented Sep 2, 2020

Does this mean that GC will no longer have an anyref type?

This GC proposal has an anyref type, which is an alias for (ref null any). It also has an externref type that is an alias for (ref null extern). They are different types, and AIUI extern <: any, as described above.

@bvibber
Copy link

bvibber commented Sep 2, 2020

Thanks for the clarification.

@dcodeIO dcodeIO closed this as completed Jan 30, 2021
rossberg added a commit that referenced this issue Feb 24, 2021
* [interpreter] Simplify zero-len and drop semantics

* Update overview

* [spec] Change drop semantics

* [spec] Forgot to adjust prose for *.init ops

* [test] Update generated tests for OOBs and dropping changes (#131)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants