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 last week was missed due to me taking some time off. Thus, this issue will cover the previous two weeks.
D 2.067.1 was released, including regression and bug fixes.
A switch was added to dmd in git to start profiling the GC itself, as part of a general push toward better memory management in D.
Improving the GC is coupled with improving facilities to avoid it. One of those improvements was an overhaul of std.typecons.Unique, using a lot of fixed language bugs to make it more generally useful and like its counterpart in C++.
The week of April 26 was a community hackaton which yielded some code. Among the most notable threads:
See more at digitalmars.D.announce.
With the hackaton last week, there was a bit less forum discussion than usual. However, a few threads stood out as significant:
Don't be afraid to do things the C way.
I've observed a lot of D programmers worrying about doing things the "D way", including asking how to convert working C standard library code to D or lamenting the lack of a D library to replace some C code.
There's value in this: D can do a lot of things C can't. The "D way" can often be safer, less bug-prone, more beautiful, or more efficient than C code and libraries.
However, D is also a language for practical programmers and sometimes code that works today is more important than ideal code that might be written at some point later. This is why D gives full access to C facilities, so you can use them!
If you know how to do something with scanf, you can still use it in D, even while mixing with std.stdio's functions. Simply import core.stdc.stdio; and you can use all your familiar C functions.
Want to do memory management the C way? Simply import core.stdc.stdlib; and use malloc and free. Combined with D features like scope(exit) to help with freeing and struct semantics to manage ownership you can rest assured that using D will offer advantages over C where needed, without tying your hands when you want to do things the old, familiar way.
If you have a third-party C API, you don't have to reimplement that functionality in D to take advantage of it (though, there are times you do want to, to leverage D's unique offers). You can simple write an extern(C) function declaration and call the function directly from D, or you can also use dynamic library loading in D, the same way as in C, e.g. with dlopen or LoadLibrary.
If you know how to solve a problem with pointers, structs, loops, and procedures as in C, you can use them in D too. Yes, the standard library offers a number of excellent range-based algorithms and help for coding in a functional programming style, and learning these is worth the investment. But, if you already know how to do it in C and need it done now, don't let Phobos' allure be an enemy to your productivity. You can still do your work with familiar language features.
Moving to D opens up a whole new world of superior programming. But it doesn't shut you out of the old world. D aims to be a practical language for working programmers - remember that as you work with it. The new features will still be there to try tomorrow.
If you'd like to submit a tip, email me.
To learn more about D and what's happening in D: