- 1 File a bug report
- 2 Discuss in the forums
- 3 Write blog posts, articles and documentation
- 4 Alpha-test the development version of D
- 5 Task List
- 6 Contribute to the source code
- 7 Review pull requests
- 8 Write a DIP about a language change
- 9 Google Summer of Code ideas
- 10 Other D-related projects
- 11 How to better promote your own D projects
- 12 Contribute to this wiki
- 13 See also
File a bug report
If you find any problems with the D language, please file a bug report. Problems that are not filed will not get fixed, because the developers wouldn't know the problem existed. If you're not sure if something is a bug or by design, please ask in the forums (see below).
Ideally, bug reports should be accompanied by a small, self-contained example which demonstrates the problem, and makes it easy to reproduce it. If you find it difficult to manually extract a small example from your source code, DustMite can help with automatically extracting one. See the project wiki for more information.
If a piece of code worked in an older version of a compiler but no longer works in a newer version, please file a regression (by setting the "Severity" field to "Regression"). Regression bugs are examined before all others. The simplest way to determine whether an issue is a regression or not is to go to run.dlang.io, paste your sample code and select "All dmd compilers" in the scrollbar next to the "Run" button. Ideally, regression reports contain the PR that introduced the regression. Digger is a great tool to find the pull request that introduced the change which broke your code. DustMite can also be helpful in creating a minimal example.
Note that compiler internal errors (crashes, assertion failures, etc.) should always be filed. No matter how wrong your input is, the compiler should give an appropriate error message and abort compilation; it should never crash. Such crashes are always bugs.
Discuss in the forums
The main D forum is for general discussion on the D language, feature requests and discussions, etc.. Newcomers should start with the D.learn forum, which is intended for learners to ask more basic questions about programming in D.
Write blog posts, articles and documentation
D doesn't have a dedicated outreach team. All blog posts about the language's awesome features, standard library, or a third-party DUB packages are very welcome. If you have an idea for a post on D's official blog, please give @mdparker a ping. You may also consider improving the DLang Tour, or work on a translation. The source code for the DTour repos can be found on GitHub.
Alpha-test the development version of D
A list of tasked relevant to the community is kept here
Contribute to the source code
Contributing to the Phobos source code
- Make sure every function in Phobos has an example ->
has_public_exampleDScanner check (see phobos/5581 for an example)
- Make sure every function in Phobos has Params: and Returns: sections ->
- Improve code coverage
- CodeCov provides an excellent overview
make -f std/ascii.testyields a
std-ascii.lstwith the coverage information
- Fix trivial issues at Phobos
More tricky tasks
- Make more functions/module
- grep for
- Guide: http://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d
- Another good resource for finding instances that could be
@safeis grepping vibe.d for
@trusted(or see vibe.d/1618)
- grep for
- Eliminate all gratuitous use of gc
- Review all Phobos modules for compatibility with ranges (std.zip, for example, was done before ranges and does not work with them)
- Fix preapproved or bootcamp issues at Phobos
Contribute to the DMD and DRuntime
The source code for the D website, compiler, runtime library, and Phobos (the standard library), are all available on GitHub. Contributions to the source code are done via pull requests. Please note that contributions to DMD source code will only be accepted if the author agrees to have the copyright of the code assigned to the D Language Foundation.
There is a pre-filtered list of trivial issues which is a good starting points for beginners. Improving compiler error messages is also often easy and a good way to become familiar with the DMD source code.
Contribute to the documentation and dlang.org
Review pull requests
The sheer amount of code being written for the D compiler, standard library and related project is often too great for the core developers to keep up. Even if you're not a "hardcore" D developer you can help lessen this load by reviewing the changes in pull requests at GitHub for DMD, Phobos, DRuntime, the D website, and the dub package manager.
Various "easy" things to look for:
- Missing or hard to understand comments
- Unintuitive documentation
- Unchecked edge cases in the code (missing assert, enforce, template constraints)
- Inconsistencies with the D style
- API inconvenient for use cases the author didn't think of
- Missing/inadequate unittests
- Poor code coverage (install the CodeCov browser extension or check
dmd -cov -unittest -main std/filename.d)
- More/better code examples in documentation. Look at answers in D.learn and stack overflow for ideas.
- Missing overflow checks when calculating storage sizes
- Drifting off topic, i.e. anything other than the PR being reviewed.
To run the unittests of a single file on Posix:
make -f posix.mak std/file.test
Also, it is often helpful to review old pull requests (e.g. sort by least recently updated on GitHub). Commenting on an old pull request that seems OK but was for some reason forgotten may bring some attention to it. If you think a pull request is OK to be merged, write "LGTM" (looks good to merge) in your comment.
If a pull you're interested in has been languishing in the queue for a long time with no attention, commenting "ping" may help prod things along. Especially if the author needs to rebase the pull due to a merge conflict, autotester failure, or other such maintenance problem.
Citing Andrei Alexandrescu:
- "If you see [Pull request] you care about, review it even if you don't have rights yet. A simple message such as "I reviewed this and LGTM, any holdup?" would be sufficient to attract attention."
Write a DIP about a language change
A D Improvement Proposal (DIP) is a formal document that details a potential feature or enhancement to the language, or the official tooling, and the rationale behind it. If you feel strongly about missing feature or would like to change a behavior, you should consider writing a DIP.
Google Summer of Code ideas
Some of the past ideas may still be interesting:
How to better promote your own D projects
I hate the movie "Field of Dreams" where they push the idiotic idea of "Build it and they will come." No, they won't. There's a blizzard of stuff competing for their attention out there, why should they invest the time looking at your stuff? You need to tell them why!
Here's the frustrating typical pattern I've seen here for years:
- spend hundreds if not thousands of hours developing something really cool
- spend 2 minutes posting a link to the repository on D.announce
- someone posts it to reddit. Ignore it
- get frustrated that nobody looks at it
- get bitter and quit
Here's the pattern that works a lot better:
- spend hundreds if not thousands of hours developing something really cool
- spend 10 minutes writing the announcement to D.announce. Be sure to include:
- who, what, where, when, why, and how
- someone posts it to reddit
- post the who, what, where, when, why and how on reddit AS SOON AS POSSIBLE after the reddit link appears. Stuff on reddit has a VERY SHORT shelf life. If it doesn't get action within a couple hours, it fades into oblivion. Identify yourself as the author, say AMA. The first one to post a comment tends to spark and set the tone for the discussion.
- check back on reddit once an hour or so for the next day, answer questions
Contribute to this wiki
- D as a second language sections should be completed
- add more examples of how to shift idiom to speak fluent D
- flesh out the Python page
- review empty sections
- update C and C++ transition guides
One note about Walter's older C/C++ transition articles. They have good information on transition technicalities (e.g. "how do I do this thing in D that I used to do in C++?") but not a lot about the changes in coding style - making object copying not arbitrarily expensive, choosing struct vs. class, preferring pipelines and lazy to eager computation, etc. From what I see some folks come from C++, write their first D program in a stilted C++ idiom, and are left with the impression that the work is not worth the trouble.