{"id":21480333,"url":"https://github.com/dlang/vision-document","last_synced_at":"2026-01-03T15:34:43.599Z","repository":{"id":42454380,"uuid":"509963034","full_name":"dlang/vision-document","owner":"dlang","description":"The high-level goals, current focus, future plans, and wishlist for the D Programming Language.","archived":false,"fork":false,"pushed_at":"2023-05-20T22:48:27.000Z","size":166,"stargazers_count":16,"open_issues_count":0,"forks_count":2,"subscribers_count":17,"default_branch":"main","last_synced_at":"2025-01-23T18:46:41.497Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/dlang.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null},"funding":{"github":"dlang","open_collective":"dlang","custom":"https://dlang.org/foundation/donate.html"}},"created_at":"2022-07-03T08:18:34.000Z","updated_at":"2024-11-21T11:44:37.000Z","dependencies_parsed_at":"2025-01-23T18:42:36.627Z","dependency_job_id":null,"html_url":"https://github.com/dlang/vision-document","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dlang%2Fvision-document","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dlang%2Fvision-document/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dlang%2Fvision-document/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dlang%2Fvision-document/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/dlang","download_url":"https://codeload.github.com/dlang/vision-document/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":244006275,"owners_count":20382443,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-23T12:14:34.789Z","updated_at":"2026-01-03T15:34:43.554Z","avatar_url":"https://github.com/dlang.png","language":null,"funding_links":["https://github.com/sponsors/dlang","https://opencollective.com/dlang","https://dlang.org/foundation/donate.html"],"categories":[],"sub_categories":[],"readme":"# The D Programming Language Vision Document\n\nThis document describes the high-level goals for the D programming language and its current\nmaintenance and development priorities according to the D Language Foundation. Those tasked with\ndirecting specific projects in the D ecosystem can use this document as an aid for establishing task\nlists and milestones. Community members interested in contributing to the D programming language can\nuse this document to determine the areas in which their contributions may have the greatest impact\non advancing the foundation's priorities.\n\nThis is a living document and can be expected to evolve with new details and additional priorities\nover time.\n\n## High-Level Vision\n\nFollowing are high-level goals that serve to provide direction for lower-level priorities and tasks.\nThe items in this section are neither concrete tasks nor specific directives. They are broad goals\nthat the foundation has identified as general targets toward which development in the D ecosystem\nshould be directed. Though we welcome contributions that are not specifically aimed at furthering\nthese goals, new ecosystem project ideas and new language feature proposals that serve to further\nthese goals are of higher priority and will have a higher chance of support and/or acceptance from\nthe maintainers.\n\nNote that the ordering of the goals in this list has no special significance.\n\n### Simplification\n\nThe D programming language and its standard library have grown in size and complexity throughout\ntheir lifetime. Both have accumulated cruft, and unwanted vestiges of D1 can still be found. This\ngoal is aimed at reducing complexity, eliminating cruft, and simplifying the user experience.\n\nThe following guidelines can assist in identifying tasks to make progress on this goal.\n\n* Identify features that have negative consequences that outweigh their benefit. Such features are\n  candidates for removal. (E.g., removing the comma operator clears the way for native tuples.)\n* Identify features that are underused, or that have proven to provide little benefit in the general\n  case. The removal of these features may be controversial, but once identified we can list them in\n  an Appendix of the spec as features that should be avoided in new code. Such features are\n  candidates for future deprecation and removal.\n* Be wary of adding complex features, or any features that increase complexity without substantial\n  benefit.\n* Streamline the syntax where possible, e.g., reduce or eliminate the verbosity resulting from the\n  use of several function attributes, commonly referred to as \"attribute soup\".\n\nThis goal extends beyond language features to encompass tooling and the ecosystem at large. The\nout-of-the-box experience is critical, and the following guidelines are intended to achieve as\nsmooth an experience as possible.\n\n* Users must not be required to install more than the minimal set of tools necessary to use a D\n  compiler beyond the compiler's installation package.\n* Language features, tools, and libraries should \"just work\" without requiring users to jump through\n  hoops.\n* The D website should leave no one behind, catering to programmers of varying skill and knowledge\n  levels.\n* Third-party tools (e.g., IDE plugins, linters) and libraries should be easily accessible and\n  well-documented, and their maintainers should have access to any available support from the D\n  Language Foundation.\n\nD users should have the best out-of-the-box user experience we can provide them. Inspiration should\nbe found by examining what works and what doesn't with other programming languages: strong IDE\nintegration, bundled tools like linters and code formatters, file monitoring, etc. Ideas and\ninitiatives that improve D's user experience are welcome.\n\n### Stronger integration with other languages\n\nStronger integration with C and other languages is a must. Multi-language projects, or multiple\ninterrelated projects using multiple languages, are more common in modern software development than\nthey once were. The ability to painlessly integrate D into existing code bases and toolchains is\ncritical to increasing adoption.\n\nThough this does increase complexity in terms of implementation, it also helps to simplify the user\nexperience. That's important when one must integrate foreign language libraries into D. One should\nnot be required to be an expert in C to use a C API from D or to compile and link C libraries with D\napplications.\n\nThis applies not just to the language, but also to tooling. It must be possible to easily set up a\nbuild system that is flexible enough to handle foreign language projects. Package management must\naccount for foreign language dependencies in some form.\n\nThis is tightly coupled with the goal of simplicity: foreign language integration should \"just work\"\nto the extent that it is technically possible.\n\n### Memory safety\n\nThe language maintainers do not see memory safety as a fad, nor is their focus on its implementation\nin the D programming language a form of \"chasing\" other languages. They see memory safety as a\ncritical component of modern programming languages going forward, as Walter Bright described [in\nthis panel exchange at DConf 2017](https://youtu.be/GcFuAptUExE?t=1424):\n\n\u003e I believe memory safety will kill C... People are tired of those expensive disasters they have\n   when they have memory corruption bugs, and malware gets in and wrecks their system and, you know,\n   destroys their customer trust in their products. They're just not going to put up with it\n   anymore.\n\nFrom the beginning, D has had memory safety features akin to those of Java (e.g., garbage collected\nmemory, array bounds checking, arrays that are fat pointers), but work remains on more advanced\nmemory safety features.\n\nFixing memory safety issues large and small is always a top goal. Beyond that, the following are the\ncurrent high-level goals for memory safety.\n\n* Allow the continued use of garbage collection as the default memory management strategy without\n  impact. The GC is one of D's strengths, and we should not \"throw the baby out with the bath\n  water\".\n* Allow `@safe` to be the default without it getting in the way. DIP 1000 is crucial to this because\n  it eliminates most of the reasons why D code written as simply as possible is not `@safe`.\n* Eliminate undefined behavior in `@safe` code.\n* Find a way to allow library writers to write `@safe` containers or smart pointers. This is not\n  possible in the current language due to aliasing issues. A good example: it's not possible to\n  write a vector type where the following code is `@safe`.\n    ```d\n    auto v = vector(1, 2, 3);\n    v ~= 4;\n    ```\n  Appending to a vector can trigger a reallocation, and therefore can only be memory safe if no\n  other aliases exist anywhere in the program to the block of memory the vector uses before the\n  append.\n* Implement proper move semantics. This means priority should be given to known issues with the\n  implementation, finishing up the move constructor DIP (or something like it), interfacing with\n  C++, etc.\n\nEven as we strive to increase memory safety in D, we must always ensure that programmers who need or\nwant to eschew memory safety features can do so. And they must be able to do so with minimal\nfriction.\n\n### Metaprogramming\n\nMetaprogramming is one of D's strongest features. However, there is room for improvement in terms of\nthe user experience. The following issues especially are of high priority.\n\n* Reduce the impact of templates on compile times.\n* Improve template error messages.\n\n### Phobos and DRuntime\n\nPhobos v2 is the future of the D standard library. We need to keep what works, abandon what doesn't,\nand repair what's broken. Some of our current goals for Phobos v2 are:\n\n* A versioning scheme that avoids breakage. Phobos v2, v3, v4, etc., should not break code using\n  older versions.\n* No autodecoding of strings. This has widely been seen as a mistake.\n* No `wstring` or `dstring`. Any functions in Phobos v2 that deal with strings should deal\n  exclusively with the `string` type. Users can convert from and to the other string types as\n  needed.\n* \"Header only\" as much as possible. Phobos v2 modules should minimize the number of link-time\n  dependencies they introduce.\n* `@nogc` as much as possible.\n* It should be possible to easily identify Phobos functions with specific attributes in the\n  documentation. E.g., a clickable link that shows all `@nogc` functions.\n* Reduce compile-time overhead, e.g., template depth, import hierarchy. This should take precedence\n  over the \"header only\" goal.\n* Be open to adding new functions, modules, etc. There is a divide between those who believe in a\n  \"kitchen sink\" standard library and those who support a minimal standard library backed up by a\n  large ecosystem. We must find a balance that makes sense for the D programming language.\n\n DRuntime must be \"pay as you go\". It should be possible for users to opt-in to DRuntime's\n requirements without paying for the features they might not use. An ideal scenario: a D program\n that does not use the `-betterC` flag but is *effectively* `-betterC` because it uses no features\n from DRuntime should behave as if the flag had been used on purpose. A fully pay-as-you-go runtime\n could make such a scenario a reality.\n\n### Stronger ecosystem\n\nWhile we work to simplify the D ecosystem by making projects more accessible and easier to use, we\nalso need to strengthen it in various ways.\n\n* Increase the number of ecosystem contributors. Many projects in the D ecosystem have only one\n  maintainer, and the majority of contributions tend to be directed to the most visible or most\n  popular projects. We must find ways to provide guidance and direction to contributors and organize\n  contributions as much as possible. This includes contributions to the core D repositories.\n* Identify mission-critical ecosystem projects. These are projects that D users find invaluable and\n  hard to live without. Such projects should receive as much support from the foundation as\n  possible.\n* Increase the number of third-party libraries. A vast and vibrant ecosystem is key to increasing\n  adoption.\n* Establish a means for users to identify and distinguish between active projects, stable projects,\n  and abandoned projects.\n* Provide automatic CI for actively-maintained third-party projects.\n* Foster a system that encourages contributors to take over abandoned projects and provide them with\n  a path to upgrade to the latest version of D.\n* Assist the maintainers of active projects such that they can more easily keep up as the language\n  evolves.\n* Strengthen editor and IDE integration. We should identify which IDEs and editors are most widely\n  used in the D community and support those that are most popular, but we should also support\n  projects that are usable across a range of IDE and editor projects, e.g., the implementation of\n  the Language Server Protocol for D.\n* Tooling for D must be competitive with tools for other languages. We must determine what sort of\n  tools are necessary for our ecosystem and actively seek out capable programmers to develop them.\n\n### Community management\n\nAs a non-profit organization, the D Language Foundation depends primarily on the work of volunteers.\nAny steps we take to bring structure to ecosystem development will be fruitless if there are no\nvolunteers with the motivation to contribute. As such, we must look for interesting and effective\nways to encourage and motivate potential contributors.\n\nNot all tasks can be accomplished by the efforts of volunteers alone. Some are too complex, or too\ntime-consuming, to fit within a volunteer's time constraints. We must take steps to increase income\nfrom donations and other sources, allocate more funding for potential contracts, identify tasks that\nare more suited to contract work, and seek out contractors to complete them.\n\nAll D users and contributors must feel comfortable participating in the D community. We recognize\nthat the D user base includes people from a variety of backgrounds with different expectations.\nFostering inclusiveness is a top priority. To meet this goal, we will adapt our moderation policy in\nthe official forums and the language used in our communications via social media as necessary. We\nare open to suggestions to help us along the way.\n\nForum threads and Discourse channels are not the most efficient means of absorbing and responding to\ncommunity feedback. We must establish ways for community members to make their voices heard in an\nenvironment that allows for a level of response appropriate to the depth of the feedback, e.g.,\ncommunity surveys for general opinions; one-on-one or small group meetings to hash out complex\nissues, etc.\n\nThe community is the lifeblood of the language. Whether one is a contributor, an active user, or a\npart-time lurker, we want all to feel welcome.\n\n### Other\n\n* __New Language Features__: This document should not be seen as a basis for the guaranteed\n  acceptance or rejection of any new language feature proposals. The goals outlined here are\n  intended to reflect the priorities and intended targets of the language maintainers so that those\n  looking to make direct contributions can understand where their efforts will have the most impact.\n  Any submitted DIPs that propose features aligned with these goals will still be evaluated on their\n  merits. Likewise, any DIPs that are not aligned with these goals. The question should never be\n  \"why not add this feature\", but \"why should we add this feature\". We should never add features\n  just because we can. The maintainers must be convinced there is a compelling reason to add a\n  feature.\n* __Possible Future Features__: Some features are worth considering for possible inclusion in the\n  future. Please note that any DIPs for items on this list are not guaranteed to be accepted. They\n  are simply features that one or both of the language maintainers have expressed interest in\n  exploring.\n  - Pattern matching\n  - Tuples\n  - Async/await\n  - Stronger traits\n* __Fixing Fundamental Frontend Bugs__: The D frontend is the foundation upon which all language\n  features are built. More important than adding new features is fixing fundamental bugs in the\n  frontend. For example, errors caused by the frontend's semantic ordering have been seen in\n  production code. Issues like this can potentially become more problematic, or more difficult to\n  resolve, with the addition of new features. We are committed to fixing these issues and welcome\n  any help in identifying and resolving them.\n\n\n## Current Priority Tasks\n\nThis section will describe the projects and tasks that are the current focus of the language\nmaintainers.\n\n## Future tasks\n\nThis section will describe the projects and tasks the language maintainers intend to prioritize in\nthe future.\n\n## Wishlist\n\nThis section will describe potential projects and tasks the language maintainers would like to\nexplore.\n\n## Contributing\n\nThis section will provide a list of specific projects and tasks, aligned with the general vision,\ntoward self-motivated contributors can direct their efforts.","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdlang%2Fvision-document","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdlang%2Fvision-document","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdlang%2Fvision-document/lists"}