This Week in D December 20, 2015

Welcome to This Week in D! Each week, we'll summarize what's been going on in the D community and write brief advice columns to help you get the most out of the D Programming Language.

The D Programming Language is a general purpose programming language that offers modern convenience, modeling power, and native efficiency with a familiar C-style syntax.

This Week in D has an RSS feed.

This Week in D is edited by Adam D. Ruppe. Contact me with any questions, comments, or contributions.

Statistics

Major Developments

Talk about the website dominated activity in the D forums and code work this week. It started with a thread offering some feedback on the site's usability and the discussion turned to visual design, implementation language, and build process.

Many people don't understand the build process, so Andrei wrote a document about contributing to the website in an attempt to clear it up. The hope is that with better documentation, people will have an easier time getting involved and improving the website content.

The website is written in DDoc, the D documentation generator. People often criticize this, but it is unlikely to change in the short term and with the process documented perhaps it will be all right to more contributors too.

We also had several ideas on how to make the content more usable, including both minor and major visual redesigns. A major issue is the difficulty of reading constraint template overloads and ideas on how to reformat them were abound. Andrei wants to change the font, and we also plan to format it with better whitespace, grouping, and perhaps even dynamic highlighting to make these signatures readable.

I also realized similar formatting improvements can help make dmd's error messages more readable and started thinking about that. My time is limited, but if I can find the time, I'd like to implement that too.

Anyway, the other big website issue that will surely get attention is linking. The D website lacks anchors in many places and those that do exist, are hard to find. As a result, linking to a part to share with someone, e.g. for discussion or to answer a question, is painful. This just needs some attention in a pull request.

Similarly, linking in the documentation of code, including the samples, is basically missing. When you see isInputRange in a constraint, you can't click it to go to the explanation of what it means. This will probably need a change to the documentation generator, but we could also fix it by adding a link to the prose of these functions. Any pull requests on the website improving these documentation would surely be accepted.

Lastly, the whole visual style of the website came under fire and an old proposal for an overhaul came back. If we want an overhaul to happen, someone will have to do the work of making it possible inside the existing framework. Andrei indicated he is open to the idea of a redesign, even if there's no major improvement, so this may happen but there is no guarantee.

A small, backward-compatible change to Throwable also went through this week: a virtual message function which can be overridden in child classes. Perhaps more changes to the exception objects are coming, as the discussion indicated that this still wasn't idea.

In the community

Community announcements

See more at the announce forum.

Tip of the Week

What are out params and how do they differ from ref params?

Think of out params as being additional return values rather than as arguments in the traditional sense and you should be ok.

D didn't used to have ref. It instead used in, out, and inout as the parameter storage classes.

in meant (and means, it is still there) that you are going to look at, but not modify or store a reference to it (the latter is what makes it distinct from const - you are allowed to store const, but not in or scope params, which lets the compiler, in theory, optimize the memory allocation of them). It is just for data consumption.

out means the function is going to store data in that variable, but is not going to look at or store it. The value that is already in there beforehand will be lost as the function writes its result to it. The compiler resets it upon function entry to guarantee the program doesn't depend on some value passed in through it.

And finally, the old inout was it would take the data in, and store a value out. Today (well, starting like five years ago), this usage is long gone and inout means something entirely different (const but returning constness is conditional on the input; the const/immutable/mutable qualifiers have the same out as they do in) and the old usage was replaced with ref.

While out is implemented as ref plus automatic reinitialization, you should remember the original meaning: you write data to it but don't do anything else. Do not take its address - that's legal with ref (unless it is scope ref or in ref...) but incorrect with out. You are supposed to write to it, nothing more.

Learn more about D

To learn more about D and what's happening in D: