From e2be77eaac770268a4c22fb09c6f648de7b9b6b8 Mon Sep 17 00:00:00 2001 From: Joseph Richey Date: Wed, 15 Nov 2017 08:48:14 -0800 Subject: Fixup links to future features (#1157) This link standardizes how all the other design pages will refer to future features (either in `FutureFeatures.md` or in a tracking issue). All links to these upcoming features now use references at the bottom of the doc page (as opposed to inline links or references). Note that this change makes it very easy for the doc links to be updated when a tracking issue is started. As all the references have a standard format; a simple find/replace script will get everything. This commit also makes sure that references now point to a tracking issue if one exists. Note that this means a future CL can now delete some of the unnecessary sections from `FutureFeatures.md`. The only visible change from this commit is that certain broken links are now fixed, or links pointing to a doc section now point to the correct tracking issue. --- FAQ.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'FAQ.md') diff --git a/FAQ.md b/FAQ.md index 88c8dd4..37e0d27 100644 --- a/FAQ.md +++ b/FAQ.md @@ -24,7 +24,7 @@ There are two main benefits WebAssembly provides: 2. By avoiding the simultaneous asm.js constraints of [AOT][]-[compilability][] and good performance even on engines without [specific asm.js optimizations][], a new standard makes it *much easier* to - add the [features :unicorn:][future features] required to reach native + add the [features :unicorn:][future general] required to reach native levels of performance. [experiments]: BinaryEncoding.md#why-a-binary-encoding-instead-of-a-text-only-representation @@ -96,7 +96,7 @@ reusing a modular C++ library can be as simple as [using a module from JavaScrip Beyond the MVP, another [high-level goal](HighLevelGoals.md) is to improve support for languages other than C/C++. This includes [allowing WebAssembly code to allocate and access garbage-collected (JavaScript, DOM, Web API) objects -:unicorn:][future dom]. +:unicorn:][future garbage collection]. Even before GC support is added to WebAssembly, it is possible to compile a language's VM to WebAssembly (assuming it's written in portable C/C++) and this has already been demonstrated ([1](http://ruby.dj), [2](https://kripken.github.io/lua.vm.js/lua.vm.js.html), @@ -178,7 +178,7 @@ together in a number of configurations: today) allowing developers to reuse popular WebAssembly libraries just like JavaScript libraries today. * When WebAssembly - [gains the ability to access garbage-collected objects :unicorn:][future dom], + [gains the ability to access garbage-collected objects :unicorn:][future garbage collection], those objects will be shared with JavaScript, and not live in a walled-off world of their own. @@ -390,7 +390,7 @@ accessible through regular JavaScript. However, if a wasm VM is provided as an access to [proprietary platform-specific APIs](Portability.md#api) of e.g. Android / iOS. -[future features]: FutureFeatures.md -[future dom]: FutureFeatures.md#gcdom-integration +[future general]: FutureFeatures.md +[future garbage collection]: https://github.com/WebAssembly/design/issues/1079 [future floating point]: FutureFeatures.md#additional-floating-point-operators [future memory control]: FutureFeatures.md#finer-grained-control-over-memory -- cgit v1.2.3