You might find this post from the D Blog interesting. Funkwerk is a German company that switched from Java to D starting in 2008, and this post describes a little of their experience.

This version of D was released November the first.

Link to the full change-log: https://dlang.org/changelog/2.083.0.html

TL;DR:

D: - Cpp runtime version check - New less conflicting way of declaring C++ linkage via a string - New trait isZero - New trait getTargetInfo - New pragma linkerDirective

Phobos: - std.algorithm.iteration.each is now capable of early-stopping

Dub: - betterC build option has been added

I think the only details missing from that page are probably the specific language features that depend on garbage collection. Those are listed here:

https://dlang.org/spec/function.html#nogc-functions

If you would, I'd love to hear why you're looking into BetterC.

A few thoughts:

• @nogc: Most of the time, you don't have to worry about it. I realize some people have this built-in aversion to garbage collection, but the situation isn't as bad as they make it out to be. It's quite useful for most apps when you account for it and architect your code for it. There is a class of apps for which D's GC will be problematic, but that does not include 2D hobby games. I linked the blog's GC series in another comment, but here it is: https://dlang.org/blog/the-gc-series/. There's some tips and tricks there for making effective use of the GC.

• @nogc and Phobos: There is no intention to ever make Phobos fully @nogc compatible. The ongoing work is looking to weed out GC usage where it isn't absolutely necessary and provide, where possible, @nogc alternatives to functions where it can't be weeded out. The goal has never been 100% compatibility.

• BetterC: No D app should start out with this unless the developer has a very specific use case and a full understanding of why it's being used. It is intended primarily to enable easier porting of C and C++ projects to D. You lose too much to justify using it (as you pointed out).

D is perfectly usable right now in a "it works" mindset rather than a "well, it kinda works" one. Major changes like safe-by-default and @live will be given ample preview periods before they become the default. That will give you time to gradually adapt your code base (e.g. do a preview compile to see what works and where you need to add @system and implement @trusted bridges). And if you don't want to adapt, you can maintain your code with an older version of the compiler (or use the -revert switch to turn off a feature). It might not be entirely headache free initially, but for your use case I expect the headaches will be minor and easily solved.

You shouldn't rely on the order of evaluation of the arguments in a function call:

> Order Of Evaluation

> Binary expressions and function arguments are evaluated in strictly left-to-right order. This is similar to Java but different to C and C++, where the evaluation order is unspecified...

> But even though the order of evaluation is well defined, writing code that depends on it is rarely recommended. Note that dmd currently does not comply with left to right evaluation of function arguments and AssignExpression.

https://dlang.org/spec/expression.html

So while there is a specified order, the reference compiler doesn't guarantee it will be honoured!

Point being a struct requires you to use braces to statically initialize it. Replace the two lines you suggested by:

Point p1 = {[2, 1]}; Point p2 = {[1, 1]};

More info here: https://dlang.org/spec/struct.html#static_struct_init

Note that above assignment works only in the same module Point is defined because double[2] p is private.

i think A. Ruppe's D cookbook addresses the language/stdlib/unit test/ddoc aspects of your bullets pretty well (but not free resource, of course): https://www.safaribooksonline.com/library/view/d-cookbook/9781783287215/

Announcement text quote:

Hi,

I've ported DWM to D as a learning exercise and thought I'd share it. The repository can be found here:

https://bitbucket.org/growlercab/ddwm

(Beware, I've only tested it on Arch-Linux 64 bit for about 1 day!)

DWM is a minimalist dynamic window manager from suckless. More details on DWM can be found here

http://dwm.suckless.org/

The "cport" branch is where I've done as little as possible to port the C code to D. It really looks like C code and is basically the DWM code compiling with DMD.

Under the "Downloads" section is a build of ddwm-cport to try out if anyone is interested, or build from source as it's pretty easy with dub.

The master branch is where I'm learning D, trying new Phobos functions and D style coding. I'm then comparing how the D-style version performs with DDWM.cport and the original DWM in terms of speed and memory.

I don't expect the master branch to be stable but cport should work fine.

Cheers, Stew

Announcement text quote:

Hi all!

Finally, LLVM 3.6 has been released! See the release notes here: http://llvm.org/releases/3.6.0/docs/ReleaseNotes.html Downloads: http://llvm.org/releases/download.html#3.6.0

Also note that LDC is mentioned in the release notes as one of the projects who are already supporting LLVM 3.6. Just recompile LDC using master branch from GitHub or from the 0.15.1 source.

This is the 6th time that LDC and D are mentioned in the LLVM release notes!

Regards, Kai

I would recommend against mixing packages, as it will complicate any debugging on imports or make it harder to switch things out later on.

But otherwise the D style guidelines has no opinion on it. https://dlang.org/dstyle.html#phobos_imports

> A small 2D-basebuilder game, with ideas from Factorio/Dwarf Fortress. But more on a hobby level.

I'll bet the bank that you really, really, really don't need to worry about @nogc for that. Just be smart about how and when you allocate just as you would in C or C++ and make use of the tools D provides if you profiling shows you GC is a problem. Please read the GC series at the D blog: https://dlang.org/blog/the-gc-series/.

you mean interoperation? but actually, no, it looks like the docs are a bit out of date https://dlang.org/spec/cpp_interface.html#cpp-namespaces

That still gives you 80% of the view though, so better than nothing.

Your best answer will come from browsing the docs and seeing how easily you find things you want:

https://dlang.org/phobos/index.html

If you really want my subjective opinion: yes, I used to feel the pain of C++'s standard library, and it's a major reason I prefer D.

D's standard library isn't as good as Python's, yet --- but "yet" is the key word. Containers are a big gap, but otherwise it's much more "batteries included" than C++'s.

> Stuff like reading individual keys like hot-keys or interacting with the filesystem (creating/deleting files and directories)

Basic file manipulation is there. Reading hot keys is something I'd do with a GUI library or something like SDL (same as with most cross-platform languages).

Personally I like the brackets. They signal Point is a structure, not an array.

If you wish to get rid of them I would eschew using structures completely, going with alias Point = double[2]; instead.
https://hastebin.com/amitipolib

Thanks!

> one big allocation on the heap isn't costly enough to worry about

That's a relief to know. In that case I'll simply pass a maximal number to the constructor.

>Read up on branch mispredictions if you haven't.

I have. With my name it's basically inevitable. ;)

>if you see one using "new" for the individual particles run away though

I've actually seen an old, often forked game which does that. It works surprisingly well for a four digit number of particles.

It probably just shows how amazingly fast computers have become.

>You could experiment with SIMD but I can't offer any guidance there.

If I wanted millions of pixels, I probably had to do all on the GPU like real AAA engines. Which looks impressive, but is kind of an overkill.

Speaking of CPU-GPU bottlenecks, do you know if it's cool if I use the SDL draw function to draw each particle or should I really put them in some kind of vertex array, similar to http://www.sfml-dev.org/tutorials/2.0/graphics-vertex-array.php ?

Is that even possible for particles? My OpenGL knowledge is rather limited.

You might want to check out libmir. Also, you can always use the C standard library through core.stdc

If you're looking for something comprehensive and feature rich like the .Net Framework, you're probably not going to find it. You'll have to piece together something from various sources.

What specific features are you looking for?

While it does not directly address your question, The D Style document does provide some guidance from which you may find some direction.

There are also some identifiers which you should avoid. Though not enforced, identifiers beginning with __ are reserved for compiler-generated identifiers, and identifiers beginning with _d_ are reserved for symbols implemented in the runtime.

The D Runtime Library also has bindings to the C Standard Library at core.stdc which you can use as a model.

Let me add a few points to this list:

• property functions, see https://dlang.org/spec/function.html#property-functions
• shared modifier is broken since it was introduced
• they are working on rebasing the class hierarchy introducing a new monitorless ProtoObject

The alias this gets the compiler to say "Point" instead of "double[2]" in error messages. It is kind of nice when dealing with more complex types.

No, unfortunately operators can be overloaded only for structures and classes. You could use one of the built in array operations which already do what one would expect but the syntax exposes Point as an array:

Point p3 = p1[] + p2[];

Doing it the nicest possible way is not going to work:

Point p3 = p1 + p2;

I like std.conv: text, it acts like writeln and is easy to remember.

override string toString() { return text("Name: ", name, ", Age: ", age); }

> How does compiler know what are the types of these lambdas, or are they untyped lambdas and compiler only instantiate them late ?

For the lambdas where no types are specified, they're instantiated late, yes. The actual code is a bit more complex, but the basic behavior is this:

switch (tag) { static foreach (i, T; Types) { case i: static foreach (fn; handlers) { static if (__traits(compiles, fn(value!T))) { return fn(value!T); } } } }

> Also how is that different than variant types?

std.variant.Variant and friends use RTTI (run-time type information), and doesn't always infer the right attributes for @nogc, @safe, pure or nothrow. Algebraic is essentially a thin skin on top of the much more powerful VariantN type, and that power comes at a cost.

Other posts answer things pretty well but I just read these posts that are more recent than both this post and its comments so I wanted to share as they are relevant:

• https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/
• http://forum.dlang.org/post/[email protected]

There's probably a more elegant way, but I'd just re-implement that .h file with D "static if" statements and versions per https://dlang.org/spec/version.html#predefined-versions .. which I see is exactly what you already linked. Yeah, that.

I seem to remember there's also a compile option ("-E" I think?) that allows D to run the preprocessor, but that could be gdc only. Alternatively, you could use a C compiler to compile that .h to C code which exports __WORDSIZE and then compile it as D (which is compatible with C code; with few exceptions, valid C is valid D).

Hello,

Demo of DlangUI Scene3D engine - Minecraft-like voxel rendering - is available for Android/ARM.

Download DlangUIMinecraftDemo.apk from https://sourceforge.net/projects/crengine/files/DlangUI/

Image is a bit corrupted with some artifacts.

On desktop it works better: dub run dlangui:dminer

Another demo of DlangUI 3d engine: dub run dlangui:d3d

DlangUI/Scene3d is simple 3D engine. Supports, cameras, lights, meshes, hierarchy of nodes, transforms, models, meshes, materials, shaders. For now, only OBJ 3d model import is implemented. No physics engine integrated so far.

Best regards, Vadim

Hello,

I've implemented initial support of Android in DlangUI.

Only armv7a architecture is supported so far.

You can downlowd sample APK: https://sourceforge.net/projects/crengine/files/DlangUI/

How to add support of Android to your DlangUI project.

Copy dlangui/android/android_project directory to you DlangUI project directory.

Probably you will want to change android package name in AndroidManifest.xml and application display name in res/values/strings.xml

Modify android_app.mk, android_build_config.mk

android_app.mk

Update LOCAL_SRC_FILES to include all your project's files.

android_build_config.mk

Update paths to Android NDK, SDK, DlangUI source directory.

Default values: export DLANGUI_DIR=$HOME/src/d/dlangui export NDK=$HOME/android-ndk-r11c export SDK=$HOME/android-sdk-linux export LDC=$HOME/ldc2-android-arm-0.17.0-alpha2-linux-x86_64 export NDK_ARCH=x86_64

Use LDC cross compiler for armv7a build according instructions

https://wiki.dlang.org/Build_LDC_for_Android#Build_a_sample_OpenGL_Android_app_ported_to_D

Announcement text quote:

I've created a set of Zeus Python scripts to allow the Dscanner to be run from inside Zeus.

The Dscanner will need to be downloaded and built form here:

https://github.com/Hackerpilot/Dscanner

The Zeus scripts can be found here:

http://www.zeusedit.com/zforum/viewtopic.php?t=7196

Note: I'm the author of Zeus, Zeus is shareware, runs natively on the Windows platform and can also be run on Linux using Wine.

Announcement text quote:

Hi all!

Finally, LLVM 3.5 has been released! See the release notes here: http://llvm.org/releases/3.5.0/docs/ReleaseNotes.html

Also note that LDC is mentioned in the release notes as one of the projects who are already supporting LLVM 3.5. Just recompile LDC using master branch from GitHub.

Regards, Kai

• Posts on the official D blog are sometimes shared on social media.
• Videos of DConf talks are posted on youtube.
• Members of the D community sometimes post about it on their own websites, or on social media.

> track lifetimes in the type system

That's how rust was designed. They made that trade-off (to the extreme) at the expends convenience and ease of use.

> can you turn the GC off and still use the standard library without it being broken yet?

Yes some do. But I personally rather use the GC. Its what GC was designed for...most of the popular languages have GC and they're doing just fine (https://www.tiobe.com/tiobe-index/). And I can turn it off when I don't need. For most use cases, using GC is very well needed, easy to use and convenient.

> lack of these features...

Anyone missing feature in particular? https://dlang.org/comparison.html

D is not a managed language. The GC will only ever run a collection during an allocation, so you use the same strategy for allocation as you do in a C or C++ game engine: preallocate as much as possible, avoid allocations in your loops. See https://dlang.org/blog/the-gc-series/.

__ctfe is a runtime variable for a reason. See the section Case Study: static if and __ctfe in H. S. Teoh's CTFE article at the D wiki. He provides an explanation.

In the list of predefined versions, there is a version identifier for BetterC mode: D_BetterC. There are also identifiers for D_Exception, D_NoBoundsCheck, unittest, and assert. These are all configurable globally on the command line, so the version identifiers can be set when the compiler starts up.

There are no identifiers corresponding to @nogc and other attributes because these are not global. They are applied on a per-function basis.

Libraries don't need to be written multiple times. The author decides up front what features to support. It's a decision between widest support possible and narrowest support. For example, if the library is configured for BetterC, any D program can use it---there's no need to provide a version that is not BetterC. If, on the other hand, the author wants to use the GC and all D features, then there's no reason to create a version of the library that drops them. That would be counterproductive!

> if this D array is not added to the GC and if this D array is no managed with expand / skrink, then soon or later the GC will eat it, leading to really weird bugs.

This only happens for objects or arrays allocated with GC (new, dup, built-in array concatenation, etc.) - the GC needs to be manually informed about them by one of the methods on the core.memory page. That's what these containers do unless you disable it with the supportGC template argument. If you allocated the object/array with Mallocator, the GC will never delete it. It's mainly an issue when you want to use a library that allocates things with new instead of letting you pick the allocator.

There's other reasons these containers can't be fully @nogc anyway: Exceptions and the destroy function.

It was announced here recently that Ethan Watson will be speaking at GDC Europe next month about Remedy's use of D in Quantum Break. He was kind enough to take a the time to provide a few words about the talk for the D Blog [1]. The reddit link is at [2].

[1] https://dlang.org/blog/2016/07/25/d-in-games-ethan-watson-of-remedy-games-goes-to-gdc-europe/ [2] https://www.reddit.com/r/programming/comments/4uioxs/from_the_d_blog_ethan_watson_on_his_gdc_europe/

Everything is relative. My choice is often between D and Nim. I prefer Nim's syntax and portability, but D's IDE / editor support is far ahead.

Nim gives the user a lot of control in the trade-off between minimal compilation lag and maximum code optimization (by choosing the C compiler), but D does as well (the choice between dmd and ldc). You need a good computer to made decent optimized binaries quickly (or rent one from the cloud on demand).

Announcement text quote:

Go to http://www.tutorialspoint.com/d_programming/d_programming_environment.htm

and click "Try It!" on the upper right hand corner of the sample code to compile it. Their D compiler installation is defective. The same is true for all such in that tutorial that I tried. I am also posting this to dlang.org as they ignored my earlier attempt to communicate about this. Here's what happens in the browser. Maybe someone else can get through to them.

Compiling the source code.... $dmd -I./ main.d -ofdemo.amx 2>&1

Error: cannot find source code for runtime library file 'object.d' dmd might not be correctly installed. Run 'dmd -man' for installation instructions. import path[0] = ./ import path[1] = /usr/local/dmd2/druntime/import import path[2] = /usr/local/dmd2/phobos import path[3] = /usr/bin/../../src/phobos import path[4] = /usr/bin/../../src/druntime/import

Announcement text quote:

With the help of @ColdenCullen, Codecov now supports D language. You can easily upload your coverage reports and utilize our many features to enhance your workflow.

Writing tests for your code is important, no question. The results of your tests is simply pass or fail without proper coverage reports. Codecov makes it easy to upload coverage metrics to get more insight into how your tests are performing.

A must have is our Browser Extension that overlays coverage reports directly in Github's interface for a seamless experience and further insight into your code.

Unlimited public repos, free forever. Unlimited private repos only $5 a month.

Learn more at https://codecov.io View examples at https://github.com/codecov/example-d Questions and comments: Twitter: @codecov

Thank you and have a great day!

Steve and the Codecov Family

more BJM related <a rel="nofollow" href="http://www.amazon.com/Declare-Nothing-Parks-Anton-Newcombe/dp/B00WZXX2NC"&gt;&lt;span class="forcewrap">http://</span><span class="forcewrap">www.ama&amp;lt;/span&amp;gt;&amp;lt;span class="forcewrap">zon.com/</span><span class="forcewrap">Declare-</span><span class="forcewrap">Nothing-Parks-</span><span class="forcewrap">Anton-</span><span class="forcewrap">Newcombe/</span><span class="forcewrap">dp/B00WZXX2NC</span></a>