├── .github └── ISSUE_TEMPLATE │ ├── config.yml │ └── suggestion.md ├── CODE_OF_CONDUCT.md └── README.md /.github/ISSUE_TEMPLATE/config.yml: -------------------------------------------------------------------------------- 1 | blank_issues_enabled : false 2 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/suggestion.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Suggestion 3 | about: Suggest an idea for F# 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | **I propose we** ... (describe your suggestion here) 11 | 12 | **The existing way of approaching this problem in F# is** ... 13 | 14 | ## Pros and Cons 15 | 16 | **The advantages of making this adjustment to F# are** ... 17 | 18 | **The disadvantages of making this adjustment to F# are** ... 19 | 20 | ## Extra information 21 | 22 | **Estimated cost (XS, S, M, L, XL, XXL):** 23 | 24 | **Related suggestions:** (put links to related suggestions here) 25 | 26 | ## Affidavit (please submit!) 27 | 28 | Please tick these items by placing a cross in the box: 29 | * [ ] This is not a question (e.g. like one you might ask on [StackOverflow](http://stackoverflow.com)) and I have searched StackOverflow for discussions of this issue 30 | * [ ] This is a language change and not purely a tooling change (e.g. compiler bug, editor support, warning/error messages, new warning, non-breaking optimisation) belonging to [the compiler and tooling repository](https://github.com/dotnet/fsharp) 31 | * [ ] This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it 32 | * [ ] I have [searched both open and closed suggestions on this site](http://github.com/fsharp/fslang-suggestions/issues) and believe this is not a duplicate 33 | 34 | Please tick all that apply: 35 | * [ ] This is not a breaking change to the F# language design 36 | * [ ] I or my company would be willing to help implement and/or test this 37 | 38 | 39 | ## For Readers 40 | 41 | If you would like to see this issue implemented, please click the :+1: emoji on this issue. These counts are used to generally order the suggestions by engagement. 42 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to making participation in our project and 7 | our community a harassment-free experience for everyone, regardless of age, body 8 | size, disability, ethnicity, sex characteristics, gender identity and expression, 9 | level of experience, education, socio-economic status, nationality, personal 10 | appearance, race, religion, or sexual identity and orientation. 11 | 12 | ## Our Standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing empathy towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others' private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our Responsibilities 35 | 36 | Project maintainers are responsible for clarifying the standards of acceptable 37 | behavior and are expected to take appropriate and fair corrective action in 38 | response to any instances of unacceptable behavior. 39 | 40 | Project maintainers have the right and responsibility to remove, edit, or 41 | reject comments, commits, code, wiki edits, issues, and other contributions 42 | that are not aligned to this Code of Conduct, or to ban temporarily or 43 | permanently any contributor for other behaviors that they deem inappropriate, 44 | threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This Code of Conduct applies both within project spaces and in public spaces 49 | when an individual is representing the project or its community. Examples of 50 | representing a project or community include using an official project e-mail 51 | address, posting via an official social media account, or acting as an appointed 52 | representative at an online or offline event. Representation of a project may be 53 | further defined and clarified by project maintainers. 54 | 55 | ## Enforcement 56 | 57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 58 | reported by contacting the project team at fsharp@fsharp.org. All 59 | complaints will be reviewed and investigated and will result in a response that 60 | is deemed necessary and appropriate to the circumstances. The project team is 61 | obligated to maintain confidentiality with regard to the reporter of an incident. 62 | Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good 65 | faith may face temporary or permanent repercussions as determined by other 66 | members of the project's leadership. 67 | 68 | ## Attribution 69 | 70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, 71 | available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 72 | 73 | [homepage]: https://www.contributor-covenant.org 74 | 75 | For answers to common questions about this code of conduct, see 76 | https://www.contributor-covenant.org/faq 77 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Welcome to F# Language and Core Library Suggestions! [![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-v1.4%20adopted-ff69b4.svg)](CODE_OF_CONDUCT.md) 2 | 3 | This repository is for suggestions about the future evolution of the F# Language and Core Library. For discussions about tooling (editor support, compiler services etc.) please see http://github.com/dotnet/fsharp. 4 | 5 | **Voting is by giving :thumbsup: reactions to an issue.** 6 | 7 | The items marked [approved-in-principle](https://github.com/fsharp/fslang-suggestions/labels/approved-in-principle) are eligible to be taken to an RFC in the [F# language design repository](https://github.com/fsharp/fslang-design). You can contribute an implementation for an RFC in the [F# development repository](http://github.com/dotnet/fsharp). 8 | 9 | **Please search for an existing suggestion before opening a new one.** Just use GitHub search over the issues in this repository. 10 | 11 | ### [View all suggestions](https://github.com/fsharp/fslang-suggestions/issues?utf8=%E2%9C%93&q=is%3Aissue%20) 12 | 13 | ### [View popular suggestions (votes by :thumbsup:)](https://github.com/fsharp/fslang-suggestions/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc) 14 | 15 | ### [View newest suggestions](https://github.com/fsharp/fslang-suggestions/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-desc) 16 | 17 | ### [View approved-in-principle suggestions](https://github.com/fsharp/fslang-suggestions/labels/approved-in-principle) 18 | 19 | ### [View started suggestions](https://github.com/fsharp/fslang-suggestions/labels/started) 20 | 21 | ### [View open suggestions (language)](https://github.com/fsharp/fslang-suggestions/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20-label%3A%22approved%20in%20principle%22%20-label%3Astarted%20-label%3A%22area%3A%20library%22) 22 | 23 | ### [View open suggestions (core library)](https://github.com/fsharp/fslang-suggestions/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20-label%3A%22approved%20in%20principle%22%20-label%3Astarted%20label%3A%22area%3A%20library%22%20) 24 | 25 | ### [View completed suggestions](https://github.com/fsharp/fslang-suggestions/issues?q=is%3Aissue+label%3Acompleted) 26 | 27 | ### [View declined suggestions](https://github.com/fsharp/fslang-suggestions/issues?q=is%3Aissue+label%3Adeclined) 28 | 29 | ### [View all archived uservoice suggestions and comments](https://github.com/fsharp/fslang-suggestions/tree/d48c35ce216e2bff148937ec028ad61e5c273fdf/archive) 30 | (the comments from that time are linked but it got 404'ed) 31 | 32 | ### [Create a new suggestion](https://github.com/fsharp/fslang-suggestions/issues/new) 33 | (have you searched for existing similar suggestions?) 34 | 35 | ## Notes on the Design Process 36 | 37 | We do not in general revisit design decisions that have already been decided. In particular there is a distinction between 38 | 39 | 1. [things we have previously decided "not to do"](https://github.com/fsharp/fslang-suggestions/issues?q=is%3Aissue+label%3Adeclined) 40 | 2. things where we decided to do X, considered Y, and by doing X implicitly decided not to do Y 41 | 3. things we thought about doing and left open the future possibility of doing them 42 | 4. things we never thought of before 43 | 44 | Most of the existing open suggestions are in category 3 or 4. In general things in categories 1 and 2 won't be reconsidered unless there is a really very strong case, e.g. because of a change in circumstance. Many suggestions will thus be closed with responses like "we considered this in F# 2.0 and decided against this". The design notes for F# 2.0-3.0 are only available in email form, we will gradually try to make them available from our archives. 45 | 46 | The decisions about moving things to "approved in principle" (and thus RFC stage) are up to the F# Language Design squad. These are currently 47 | * [Don Syme](https://github.com/dsyme) 48 | * [Vlad Zarytovskii](https://github.com/vzarytovskii) 49 | * [Tomas Grosup](https://github.com/T-Gro) 50 | 51 | Where necessary [Don Syme](https://github.com/dsyme) will act as final decision maker. This squad is just people who have the right to label issues - putting that aside everyone should please consider themselves equal contributors. We are open to diversifying this squad further, please see [this note from Don Syme](https://github.com/fsharp/fslang-suggestions/issues/1403). 52 | 53 | Votes are just used as an indicator. A huge range of factors go into the decision to "approve in principle", including: 54 | 55 | * estimated utility 56 | * estimated cost of implementing 57 | * completeness of proposed design (is this an "idea" or a concrete suggestion) 58 | * availability of alternatives 59 | * education/learning paths and simplicity 60 | * whether this gives multiple ways to achieve the same thing 61 | * votes 62 | * design coherence 63 | * "less is more" design considerations 64 | * likelihood of breaking change 65 | * strategic importance 66 | * usefulness (or otherwise) for interop with .NET and other languages 67 | * risk of churn w.r.t. bugs 68 | * cost of churn w.r.t. education materials (new editions of books etc.) 69 | * whether someone is willing to step up to the plate to write an RFC, implement the change and own it long term 70 | 71 | Also we have a large queue of relatively small-cost ["approved in principle" items](https://github.com/fsharp/fslang-suggestions/labels/approved-in-principle), and a large (and occasionally growing) number of bugs/issues in http://github.com/dotnet/fsharp. Getting through these is also a priority. 72 | 73 | ## When are new features a good thing? 74 | 75 | Adding endless new language features in every version has major downsides. Here are some observations on why adding features is not necessarily a good thing: 76 | 77 | 1. Stability is a virtue 78 | 2. _Gradual_ evolution is good 79 | 3. Adding new language features on every version is not a necessarily a sign of strength. Many languages have spread very widely while remaining very stable (e.g. Java in 2000-2013) 80 | 4. The addition of new features on every version can be a sign that language implementors are being incentivized (e.g. getting paid) for feature-completion rather than overall simplicity and utility. 81 | 5. New features add learning costs to every user of the language 82 | 83 | In contrast, features which make the language more orthogonal, simpler and easier to use are generally a very good thing. 84 | 85 | ## What about optional features? 86 | 87 | There's a strong bias in the language design (and likewise in many other language designs) against optional features which effectively turn the language into a slightly different language ("bifurcate the language"). 88 | 89 | There are many social reasons for avoiding such optional features - e.g. when you code review code, or have two programmers meeting in a team and having to decide on standards - it's one thing to have to decide on coding conventions and design idioms, it's another to have to turn the knobs and dials on the language to select what's allowed. 90 | 91 | For this reason making a feature optional will generally not used as an approach, though exceptions may be made in some cases (e.g. checked arithmetic is optional in both F# and C#). 92 | 93 | ## How do I get my favourite feature approved? 94 | 95 | First make sure the issue for your feature is really clear and addresses all major concerns. 96 | 97 | Probably the best thing you can do to get a feature promoted is to draft an RFC on it, even if it has not yet been marked "approved". A prototype implementation of high quality, with tests, can also help convince. 98 | 99 | ## Code of Conduct 100 | 101 | This repository is governed by the [Contributor Covenant Code of Conduct](https://www.contributor-covenant.org/). 102 | 103 | We pledge to be overt in our openness, welcoming all people to contribute, and pledging in return to value them as whole human beings and to foster an atmosphere of kindness, cooperation, and understanding. 104 | 105 | We additionally request that the use of the personal pronon "you" (referring to a specific person) should be minimized in discussions. The use of the word is common, and often doesn't refer to an individual, but an effort should please be made to make technical points in a non-personal way, addressing the technical matter, rather than the person. A simple technique is to draft your contribution and check for the number of uses of "you" and reduce out unnecessary uses. If an ad-hominem or otherwise overly personalized mode is used for technical argument the moderators may hide or delete these contributions, requesting that content be reposted without making arguments in this way. 106 | 107 | --------------------------------------------------------------------------------