Thread overview
OpenD update - null pointer error shipped, among others
1 day ago
Adam D. Ruppe
1 day ago
Sergey
1 day ago
Dejan Lekic
1 day ago
Adam D. Ruppe
18 hours ago
Element Green
16 hours ago
Adam D. Ruppe
1 day ago

Been a while since I posted here, but thought you might be interested in an update.

OpenD continues to ship its rolling release with a focus on stability and common sense incremental improvements to the user experience.

Among the recent changes (very few of which break your existing code!) https://opendlang.org/changes.html:

Note that many other pointer operations require @system to ensure you aren't accidentally misusing them as part of OpenD's "safer by default".

  • Stack traces are abbreviated, trying to focus on relevant info. https://dpldocs.info/this-week-in-d/Blog.Posted_2025_05_26.html

  • with(auto x = thing) { ... } works.

  • __module supported in ImportC, so you can make a better integrated C bridge file.

  • Heredoc strings have automatic outdenting, similar to C#. See: https://dpldocs.info/this-week-in-d/Blog.Posted_2025_02_20.html#outdenting-heredoc-strings

  • import("file") will just work if file is located next to the source file.

  • static foreach(...) static if(is(X Y)) ... works without redefined identifier errors.

  • Tuple destructuring works.

    // unpack declarations
    auto (a, (b, c)) = t(1, t(2, "3"));
    assert(t(a, b, c) == t(1, 2, "3"));
    
  • foreach(int a, item; some_array) works, it puts out a runtime assert that some_array.length fits in an int so you don't have to cast.

  • pragma(explicit_gc) lets you trigger nogc checks locally but still call other gc functions if you want.

And I think I already posted here about some of these older changes, but among other things that shipped more like a year ago:

  • OpenD IES permits i"$foo", without parenthesis around simple interpolated variable names.

  • We ship dmd and ldc together, built from the same codebase, so features come on both at the same time.

  • The compiler prohibits mutable data in static initializers, so

     class A {
        int[] a = [1, 2, 3];
     }
    
     A obj = new A;
     obj.a[0] = 0;
    
     A obj2 = new A;
     assert(obj.a[0] == 0); // this is the case upstream, but opend will make you clarify your intent with an attribute or point you toward putting the initialization in a constructor.
    
  • Easy cross-compilation to Windows and browser via Emscripten (requires installing emscripten from their website). Likely more coming soon. https://dpldocs.info/this-week-in-d/Blog.Posted_2024_10_25.html for shipped info and https://dpldocs.info/this-week-in-d/Blog.Posted_2025_06_09.html#other-experimentation for likely next steps.

  • private(this) is available to move the privacy barrier to the class rather than the module if you need it.

  • Lots of old bugs in dmd have been fixed in opend including one with classes inheriting from abstract classes that require interfaces crashing at runtime instead of being a compile error, -lib and -shared filenames being broken.

  • extern(Objective-C) and @section works on both compilers. You might have seen the Objective-C stuff as it also shipped in upstream ldc (thanks Luna for doing the backport and fixing a couple bugs I missed!).

And more. These are generally little things that just now work the way you'd expect they always should have, so it is easy for me to even forget the changes!

You can always download the latest rolling release from here:

https://github.com/opendlang/opend/releases/tag/CI

And to keep up on changes, I try to update my blog about once a month with a summary of changes:

https://dpldocs.info/this-week-in-d/Blog.html

1 day ago

On Tuesday, 10 June 2025 at 13:19:42 UTC, Adam D. Ruppe wrote:

>

Been a while since I posted here, but thought you might be interested in an update.

Thanks Adam, for posting fresh news!

1 day ago

On Tuesday, 10 June 2025 at 13:19:42 UTC, Adam D. Ruppe wrote:

>

Been a while since I posted here, but thought you might be interested in an update.

OpenD continues to ship its rolling release with a focus on stability and common sense incremental improvements to the user experience.

Impressive!

Could some of the upstream D guys merge the with(auto x = thing) { ... } change? I am waiting for this for years!

1 day ago

On Tuesday, 10 June 2025 at 16:06:04 UTC, Dejan Lekic wrote:

>

Could some of the upstream D guys merge the with(auto x = thing) { ... } change?

Here's how we implemented it:
https://github.com/opendlang/opend/commit/44f7ce5f3e1ebd8a8dc3630b7cbfa8416eb0c271

And while looking at the log of that file, here's the heredoc outdent patch:
https://github.com/opendlang/opend/commit/c2937ab3719ed0cb9589e0baa6f52a84a56ddb07

(and i forgot to mention 0o777 octal literals are in opend too, again, a very small, self-contained patch: https://github.com/opendlang/opend/commit/7a5f6c283181e4bb0a1ed076c4050a833bb54cd6 )

These are nice because the behavior they change was an error previously and it has almost no interaction with anything else, so minimal risk of breakage.

and the interpolated identifier thing without parens also a simple patch: https://github.com/opendlang/opend/commit/9ddff7a6ddd3bb563d996392b26e1e16fb334285

but that is a slight behavior change so a bit more risk of breakage, though it has never been a problem in practice to opend users.

>

I am waiting for this for years!

The opend download link is right here right now :)

You can most likely adapt your current stuff to it by downloading then using dub --compiler=/path/to/opend/bin/dmd or similar too; the opend system is all self-contained so you can use it in-place without overwriting any other versions you have.

18 hours ago

On Tuesday, 10 June 2025 at 13:19:42 UTC, Adam D. Ruppe wrote:

>

Awesome stuff! The tuple destructing, with auto, and foreach(int a, item; some_array) improvements are definitely my favorite and things I have encountered before that I thought should work, but didn't. Quoted above is an ordered list of changes I personally find the most interesting for reference. Looking forward to these being available in upstream or OpenD becoming a more widely accepted D standard.

16 hours ago

On Wednesday, 11 June 2025 at 13:17:26 UTC, Element Green wrote:

> >
  • import("file") will just work if file is located next to the source file.

Here's my blog announcement about this:
https://dpldocs.info/this-week-in-d/Blog.Posted_2024_09_30.html#import-expressions-do-not-always-need--j

Note that it is different than -J.. Upstream -J. loads the import("file") from the build directory, OpenD import("file"), without requiring a cmd line switch, builds from the source directory.

As a library author and distributor, I find this behavior a lot more useful - compiled-in files are extensions of the source code, so it makes sense to put them with the source code. And when you use multiple libraries, they probably don't want to overwrite and override each other, so encapsulating it to the lib is sure to work better.

Of course, the same rules work for your own application code too, you can import stuff from your source in your modules too, it all just works out of the box. And then you can assign it to immutable byte arrays or strings (if you use auto it is a string for historical reasons - remember opend aims to be more stable than upstream as well, unless there's a compelling benefit to justify the change - but if you specify immutable(ubyte)[], it just works, no cast necessary. I think this is also true upstream nowadays.)

I've been pretty happy with it.

>

favorite and things I have encountered before that I thought should work, but didn't.

Yes, exactly. I've been writing D for about 19 years now, there's some things I just got used to so I have my blind spots, but there's also things that I still think ought to just work. OpenD is getting closer and closer to plugging these holes though.

As you can see from the commits, most of these aren't terribly complicated to implement.

(some things that are more complicated to implement is like if(auto x; tryGetFoo(x)), we're still working on that, hopefully some day. but in the mean time when pain hits, we're open to fixing it)