<table> <tr> <th>Language feature</th> <th>Scheduled for</th> <th>Notes</th> </tr> <tr> <td>Automatic dereference in more contexts</td> <td>implemented but needs to be activated via the .experimental switch</td> <td>a.f() and f(a) are rewritten to f(a[]) if overloading resolution fails completely. This rewrite is only performed for the first argument</td> </tr> <tr> <td>Implement static[T] properly</td> <td>for version 1.0</td> <td>The implementation has lots of issues, but what's worse the spec is not nearly clear enough and seems to conflate 2 different ideas.</td> </tr> <tr> <td>Support overloading of the assignment operator</td> <td>for version 1.0</td> <td>like <tt class="docutils literal"><span class="pre">fields</span></tt> and destructors an assignment operator needs to be lifted</td> </tr> <tr> <td>asFunc pragma</td> <td>After 1.0</td> <td>provides a nice bridge from 'var T' to 'returns T'; can be entirely implemented as a macro with the upcoming types API </tr> <tr> <td>Extended macros API</td> <td>after 1.0</td> <td>missing: an API for working with types; the builtin getImpl</td> </tr> <tr> <td>Pragmas are not supported for 'bindSym'</td> <td>after 1.0</td> <td>this makes clean macros impossible to write when it comes to pragmas</td> </tr> <tr> <td>Alias analysis needs to specified and controllable with pragmas</td> <td>after 1.0</td> <td>alias analysis affects memory safety rules</td> </tr> <tr> <td>Destructors need to interact with finalizers</td> <td>after 1.0</td> <td>destructors and finalizers are implemented, but do not interact. <tt class="docutils literal"><span class="pre">new</span></tt> which takes a finalizer needs to be deprecated. People should use a destructor instead. However, destructors should ultimately depend on an escape analysis.</td> </tr> <tr> <td><tt class="docutils literal"><span class="pre">~</span></tt> Operator for effects</td> <td>after 1.0</td> <td>it is not entirely clear what <tt class="docutils literal"><span class="pre">~F</span></tt> should mean.</td> </tr> <tr> <td>Prevent object branch transitions from low(selector)</td> <td>after 1.0</td> <td>object branch transitions from low(selector) are allowed, because they are simply too useful, but can break memory safety. Now that the language has a proper notion of construction, we can make them safe.</td> </tr> <tr> <td>Push pragma needs to be reworked</td> <td>after 1.0</td> <td>it should be distinguished between 'push' for 'type', 'proc' etc.</td> </tr> <tr> <td>Returning 'var T' is unsafe and needs static analysis to make safe</td> <td>after 1.0</td> <td>the compiler already checks for trivial examples</td> </tr> <tr> <td>Some effects like <tt class="docutils literal"><span class="pre">GCMem</span></tt> don't need to be white-listed</td> <td>after 1.0</td> <td>unclear whether this only affects built-in properties like <tt class="docutils literal"><span class="pre">GCMem</span></tt>, <tt class="docutils literal"><span class="pre">Recursive</span></tt>.</td> </tr> <tr> <td>Term rewriting macros need more love</td> <td>after 1.0</td> <td>we need much more tests and use them in production</td> </tr> <tr> <td>Weaken the requirements for forward declarations</td> <td>after 1.0</td> <td>two different design ideas exist: one conservative and so will work, the other highly experimental</td> </tr> <tr> <td>Write tracking</td> <td>after 1.0</td> <td>algorithm exists. Can be extended to compute lent pointers.</td> </tr> </table> <br> <table> <tr> <th>Compiler feature</th> <th>Scheduled for</th> <th>Notes</th> </tr> <tr> <td>Deterministic code generation</td> <td>after 1.0</td> <td>deterministic code generation makes C code caching much more effective</td> </tr> <tr> <td>High level optimizer</td> <td>after 1.0</td> <td>use the effect system for optimizations; interacts with TR macros; performs:<ul> <li>GCSE</li> <li>loop invariant hoisting</li> <li>escape analysis for string/seq</li> <li>inlining of small lambdas</li> </ul> </td> </tr> <tr> <td>GPU backend</td> <td>after 1.0</td> </tr> <tr><td>Pure RC'ing GC</td> <td>unknown</td> <td>important for better interoperability with Objective-C</td> </tr> <tr> <td>Symbol files</td> <td>after 1.0</td> <td>symbol files provide true incremental compilation beyond the caching of generated C code</td> </tr> </table>