Refactor future features

This refactoring clarifies points made in #53, #99, #81, and overall tries to make the text more self-coherent, less bullet-pointy.

1 files changed, 66 insertions, 50 deletions

diff --git a/FutureFeatures.md b/FutureFeatures.md
index f33bc58..cc6cc39 100644
--- a/FutureFeatures.md
+++ b/FutureFeatures.md
@@ -8,69 +8,85 @@ to be standardized immediately after the MVP. These will be prioritized based on
 developer feedback, and will be available under [feature tests](FeatureTest.md).
 
 ## Great tooling support
+
 This is covered in the [tooling](Tooling.md) section.
 
 ## Dynamic linking
- * [Dynamic loading](MVP.md#code-loading-and-imports) is in [the MVP](MVP.md), but all loaded modules have
-   their own [separate heaps](MVP.md#heap) and cannot share [function pointers](MVP.md#function-pointers).
- * Support both load-time and run-time (`dlopen`) dynamic linking of both
-   WebAssembly modules and non-WebAssembly modules (e.g., on the web, ES6
-   ones containing JS), sharing the heap as well as function pointers.
- * TODO
+
+[Dynamic loading](MVP.md#code-loading-and-imports) is in [the MVP](MVP.md), but
+all loaded modules have their own [separate heaps](MVP.md#heap) and cannot share
+[function pointers](MVP.md#function-pointers). Dynamic linking will allow
+developers to share heaps and function pointers between WebAssembly modules, but
+requires an implementation which properly handle ABI compatibility.
+
+WebAssembly will support both load-time and run-time (`dlopen`) dynamic linking
+of both WebAssembly modules and non-WebAssembly modules (e.g., on the web, ES6
+ones containing JavaScript).
+
+Dynamic linking is especially useful when combined with a Content Distribution
+Network (CDN) such as [hosted libraries][] because the library is only ever
+downloaded and compiled once per user device. It can also allow for smaller
+differential updates, which could be implemented in collaboration with
+[service workers][].
+
+Security-wise, dynamic linking and CDNs should be combine with [CORS][] and
+[subresource integrity][].
+
+  [hosted libraries]: https://developers.google.com/speed/libraries/
+  [service workers]: http://www.w3.org/TR/service-workers/
+  [CORS]: http://www.w3.org/TR/cors/
+  [subresource integrity]: http://www.w3.org/TR/SRI/
 
 ## Finer-grained control over memory
- * `mmap` of File, `madvise(MADV_DONTNEED)`, ...
- * TODO
+
+* `mmap` of files.
+* `mmap` with `MAP_FIXED`, which is often used as a performance optimization for
+  tools such as address sanitizer for its shadow memory.
+* `madvise(MADV_DONTNEED)`.
+* Shared memory, in the same WebAssembly module as well as across modules.
 
 ## More expressive control flow
- * Some types of control flow (esp. irreducible and indirect) cannot be
-   expressed with maximum efficiency in WebAssembly without patterned output by
-   the relooper and [jump-threading](http://en.wikipedia.org/wiki/Jump_threading)
-   optimizations in the engine.
- * Options under consideration:
-   * No action, while+switch and jump-threading are enough.
-   * Just add goto (direct and indirect).
-   * Add [signature-restricted Proper Tail Calls](FutureFeatures.md#signature-restricted-proper-tail-calls).
-   * Add new control-flow primitives that address common patterns.
+
+* Some types of control flow (esp. irreducible and indirect) cannot be expressed
+  with maximum efficiency in WebAssembly without patterned output by the
+  relooper and [jump-threading](http://en.wikipedia.org/wiki/Jump_threading)
+  optimizations in the engine.
+* Options under consideration:
+  * No action, while+switch and jump-threading are enough.
+  * Just add goto (direct and indirect).
+  * Add [signature-restricted Proper Tail Calls](FutureFeatures.md#signature-restricted-proper-tail-calls).
+  * Add new control-flow primitives that address common patterns.
 
 ## GC/DOM Integration
- * Access to certain kinds of GC things from variables/arguments/expressions
- * Ability to GC-allocate certain kinds of GC things
- * Initially, things with fixed structure:
-   * JS strings
-   * JS functions (as callable closures)
-   * Typed Arrays
-   * [Typed objects](https://github.com/nikomatsakis/typed-objects-explainer/)
-   * DOM objects via WebIDL
- * Perhaps a rooting API for safe reference from the linear address space
- * TODO
+
+* Access to certain kinds of Garbage-Collected (GC) objects from variables,
+  arguments, expressions.
+* Ability to GC-allocate certain kinds of GC objects.
+* Initially, things with fixed structure:
+  * JavaScript strings;
+  * JavaScript functions (as callable closures);
+  * Typed Arrays;
+  * [Typed objects](https://github.com/nikomatsakis/typed-objects-explainer/);
+  * DOM objects via WebIDL.
+* Perhaps a rooting API for safe reference from the linear address space.
 
 ## Heaps bigger than 4GiB
-* Allow heaps greater than 4GiB.
-* Provide load/store operations that take 64-bit address operands; `int64` becomes the
-  canonical pointer type.
-* On a 32-bit system, heaps must still be <4GiB so all the int64 arithmetic (which will be much
-  slower than 32-bit arithmetic) will be unnecessary.
-  * Should we provide a uintptr_t (only 64-bit on 64-bit systems)?
-    * This feature alone would not allow a C++ compiler to write size-polymorphic code since the word
-      size is also baked into the code in a hundred other ways (consider `offsetof`).
-    * The compiler *could* inflate all pointer types that are used in heap storage to 64-bit (so the
-      uintptr_t type was only used for local variable/expression types).
-      * This would imply an implicit truncation of any load of a pointer from the heap which could cause
-        subtle bugs if the pointer was storing a real int64-width value.
-      * This would still unnecessarily increase heap size on 32-bit; applications sensitive to OOM would
-        still want a separate 32-bit build.
-      * Now there are three compile targets: all-32, all-64, and this uintptr_t hybrid.
-    * More discussion and experimentation needed.
-      * Would the hybrid mostly Just Work?
-      * Are there users who would want to ship a hybrid build instead of two 32- and 64-bit builds
-        (conditionally loaded after a feature test)?
+
+WebAssembly will eventually allow heaps greater than 4GiB by providing
+load/store operations that take 64-bit address operands. Modules which opt-in to
+this feature have `int64` as the canonical pointer type.
+
+On a 32-bit system, heaps must still be smaller than 4GiB. All 64-bit pointer
+arithmetic arithmetic (which will be much slower than 32-bit arithmetic) will be
+therefore unnecessary.
 
 ## Source maps integration
- * Add a new source maps [module section type](MVP.md#module-structure).
- * Either embed the source maps directly or just a URL from which source maps can be downloaded.
- * Text source maps become intractably large for even moderate-sized compiled codes, so probably
-   need to define new binary format for source maps.
+
+* Add a new source maps [module section type](MVP.md#module-structure).
+* Either embed the source maps directly or just a URL from which source maps can
+  be downloaded.
+* Text source maps become intractably large for even moderate-sized compiled
+  codes, so probably need to define new binary format for source maps.
 
 ## Signature-restricted Proper Tail Calls
 * See the [asm.js RFC](http://discourse.specifiction.org/t/request-for-comments-add-a-restricted-subset-of-proper-tail-calls-to-asm-js).