This Week in D January 25, 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.

This Week in D is in the process of being hosted at dlang.org. Starting soon, you'll be able to find this publication there.

Last Week's Events

Silicon Valley first meetup went well and others are planned.

Walter Bright's talk at Microsoft was packed and had plenty of questions. Video is available on YouTube and a summary was written on the Rust forums, indicating a great deal of interest in the topic: "This could be a killer feature for D".

Walter's talk also got some discussion on Reddit.

The Berlin meetup happened and "was nice". More information will be available later, and the event is expected to happen again.

Statistics

Major Changes

In the community

DConf 2015

We're one month away from the talk submission deadline. If you have something to say about D at the conference, please submit soon!

Hope to see you there!

Community announcements

See more at digitalmars.D.announce.

Significant Forum Discussions

See more at forum.dlang.org and keep up with community blogs at Planet D.

Tip of the week

This week, we'll explore the D module and import system. Specifically, facilities it offers to avoid symbol conflicts.

The module and import system are documented under "modules" on the website.

When you get a symbol conflict, it can be somewhat frustrating:

import arsd.dom;
import std.xml;

void main() {
	auto document = new Document();
}

Results in: Error: arsd.dom.Document at dom.d(3389) conflicts with std.xml.Document at dmd2/linux/bin32/../../src/phobos/std/xml.d(538)

arsd.dom and std.xml are both libraries for dealing with XML and have a number of similar classes that share names. If you were to import just one, the main function would compile without issue, but importing both libraries leads to ambiguous naming.

To solve the problem, use the fully-qualified name at the usage site:

import arsd.dom;
import std.xml;

void main() {
	auto document = new arsd.dom.Document();
}

Then, the code will compile. Note that you only need to use the full name when a conflict occurs, which is typically on type instantiations or calls to free functions. You don't need to disambiguate class member calls because the type itself is already clear:

void main() {
	auto document = new arsd.dom.Document();
	// since the compiler knows document is of type arsd.dom.Document,
	// this works even if std.xml's Document also has a text property
	document.text = "foo";
}

While disambiguation is somewhat rare, using the fully-qualified name can get verbose. D offers two facilities to make it easier: static imports and renamed imports.

A static import works like any other import except that it always requires its symbols to be fully qualified, which keeps them from conflicting:

static import arsd.dom;
import std.xml;

void main() {
	// compiles without conflict - since arsd.dom is
	// statically imported, it's Document class must be
	// referred to as arsd.dom.Document, meaning plain
	// Document is unambiguously referring to std.xml.Document
	auto document = new Document();

	// the fully-qualified names from arsd.dom are still available too:
	auto other_document = new arsd.dom.Document();
}

A renamed import lets you customize the fully-qualified name at the usage point. Otherwise, it works like any other import:

	import dom = arsd.dom; // syntax is yourname = original.name;
	import x = std.xml;

	void main() {
		// loads arsd.dom.Document with a shorter, custom name
		auto document = new dom.Document();

		// loads the std.xml document
		auto d2 = new x.Document();
	}

You may combine import features, in other words, you may write static import dom = arsd.dom; and have a static renamed import which must be accessed by the full name, but you set the full name to be something you want.

Another import-related issue people can have is that functions are not overloaded across module boundaries, even if the argument types are unambiguous, unless you alias both functions to the same name in your module explicitly. Learn more in the article about function hijacking.

D's import system has more features too, including a list of symbols to import, public imports, and others. Read the documentation page and other resources on the website or D books to learn more.

Find more D tips at the D idioms list or buy my D Cookbook for a more in-depth examination of many D tricks.

If you'd like to submit a tip, email me.

Upcoming events

Learn more about D

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