From 93e4e3b2d27884bf0cc989bed4f1161074804ada Mon Sep 17 00:00:00 2001 From: Brad Nelson Date: Thu, 27 Oct 2016 20:58:36 -0700 Subject: Tagging future features with icon. (#839) Added brief item on multiple return. --- FeatureTest.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) (limited to 'FeatureTest.md') diff --git a/FeatureTest.md b/FeatureTest.md index 14e3bad..5d53faa 100644 --- a/FeatureTest.md +++ b/FeatureTest.md @@ -2,8 +2,9 @@ See [rationale](Rationale.md#feature-testing---motivating-scenarios) for motivat # Feature Test -[PostMVP](PostMVP.md), applications will be able to query which features are -supported via [`has_feature` or a similar API](PostMVP.md#feature-testing). This +[PostMVP :unicorn:][future general], applications will be able to query which features are +supported via +[`has_feature` or a similar API :unicorn:][future feature testing]. This accounts for the pragmatic reality that features are shipped in different orders at different times by different engines. @@ -40,15 +41,15 @@ it can be constant-folded by WebAssembly engines. To illustrate, consider 4 examples: -* [`i32.min_s`](FutureFeatures.md#additional-integer-operators) - Strategy 2 +* [`i32.min_s` :unicorn:][future integer] - Strategy 2 could be used to translate `(i32.min_s lhs rhs)` into an equivalent expression that stores `lhs` and `rhs` in locals then uses `i32.lt_s` and `select`. -* [Threads](PostMVP.md#threads) - If an application uses `#ifdef` extensively +* [Threads :unicorn:][future threads] - If an application uses `#ifdef` extensively to produce thread-enabled/disabled builds, Strategy 1 would be appropriate. However, if the application was able to abstract use of threading to a few primitives, Strategy 2 could be used to patch in the right primitive implementation. -* [`mprotect`](FutureFeatures.md#finer-grained-control-over-memory) - If engines +* [`mprotect` :unicorn:][future memory control] - If engines aren't able to use OS signal handling to implement `mprotect` efficiently, `mprotect` may become a permanently optional feature. For uses of `mprotect` that are not necessary for correctness (but rather just catching bugs), @@ -96,5 +97,11 @@ polyfill would then replace `foo` with `foo_f64x2` if coarser granularity substitution. Since this is all in userspace, the strategy can evolve over time. -See also the [better feature testing support](FutureFeatures.md#better-feature-testing-support) +See also the [better feature testing support :unicorn:][future feature testing] future feature. + +[future general]: PostMVP.md +[future feature testing]: PostMVP.md#feature-testing +[future integer]: FutureFeatures.md#additional-integer-operators +[future thread]: PostMVP.md#threads +[future memory control]: FutureFeatures.md#finer-grained-control-over-memory -- cgit v1.2.3