Proposal Template ================= This document provides a starting point for a larger feature proposal. The sections in it are suggested, but can be removed if they don't make sense for a chosen feature. The first section should provide a concise description of **what** the feature is and, if possible, **why** it is important. A proposal for a Slang language/compiler feature or system should start with a concise description of what the feature it and why it could be important. Status ------ Note here whether the proposal is unimplemented, in-progress, has landed, etc. Background ---------- The background section should explain where things stand in the language/compiler today, along with any relevant concepts or terms of art from the wider industry. If the proposal is about solving a problem, this section should clearly illustrate the problem. If the proposal is about improving a design, it should explain where the current design falls short. Related Work ------------ The related work section should show examples of how other languages, compilers, etc. have solved the same or related problems. Even if there are no direct precedents for what is being proposed, there should ideally be some points of comparison for where ideas sprang from. Proposed Approach ----------------- Explain the idea in enough detail that a reader can concretely know what you are proposing to do. Anybody who is just going to *use* the resulting feature/system should be able to read this and get an accurate idea of what that experience will be like. Detailed Explanation -------------------- Here's where you go into the messy details related to language semantics, implementation, corner cases and gotchas, etc. Ideally this section provides enough detail that a contributor who wasn't involved in the proposal process could implement the feature in a way that is faithful to the original. Alternatives Considered ----------------------- Any important alternative designs should be listed here. If somebody comes along and says "that proposal is neat, but you should just do X" you want to be able to show that X was considered, and give enough context on why we made the decision we did. This section doesn't need to be defensive, or focus on which of various options is "best". Ideally we can acknowledge that different designs are suited for different circumstances/constraints.