Clarify design constraints

[qwertie]

This proposal (which I assume is 100% described here?) is a little challenging to understand because

• It doesn't put the GC in context of the existing infrastructure (JS objects, linear memory)
• Key design constraints are left implicit or vaguely described (e.g. security requirements, and requirements driven by the GC's need to "understand" the heap. Isn't there a security requirement, for example, that a GC pointer must never be convertible to an integer?)

I suggest expanding the "challenges" list to describe the challenges in more detail. I would be particularly interested to know about any elements of the design that slow down execution or use extra memory for a security reason. (Looks like the downcasts used in closures and derived classes are required due to the simplicity of the current proposal.)

I'm curious if this proposal could support the D programming language. The D language has both GC and non-GC memory, and its normal pointer type is an "agnostic" pointer that "doesn't know" if it points to GC memory or not - the user can use it either way.

[qwertie]

I'd like to add that this code in Overview.md doesn't seem to make sense. Perhaps $outer meant to create $inner-clos? And shouldn't those i32 fields be f64? And in the code above it, shouldn't float be f64?

(type $code-f64-f64 (func (param $env (ref $clos-f64-f64)) (param $y f64) (result f64)))
(type $clos-f64-f64 (struct (field $code (ref $code-f64-f64)))
(type $inner-clos (struct (extend $clos-f46-f64) (field $x i32) (field $a i32))

(func $outer (param $x f64) (result (ref $clos-f64-f64))
  (ref_func $inner)
  (get_local $x)
  (f64.add (get_local $x) (f64.const 1))
  (new $clos-f64-f64)
)

[rossberg]

@qwertie, yeah, some of these requirements aren't stated explicitly, mostly because they were kind of "obvious". But I agree it wouldn't harm elaborating more. There still are a lot of explicit and implicit TODOs here. (Happy to accept pull requests, btw. :) )

I don't think there is a way to directly allow D's interconversion, since that seems inherently unsafe. The closest you could get probably is representing its pointer type as an anyref, which is either an intref pointing into linear memory, or an opaque reference. But that might require a lot of down casts. The other option of course is to forgo the built-in GC when compiling D.

Fixed the example, thanks for pointing out!

[tlively]

Closing this because the proposal is now in phase 3 and fairly stable. PRs improving the documentation would still be welcome.