DConf 2026 in London

Or you can assume exceptions can be thrown and capture and log coming from a base class in a centralized place (and probably refine incrementally what to do with each group without dirtying all the logic inside the functions themselves).

For Rust result in C++ you have optional and expected. But they have their own problems, like rewriting function signatures all the way up the stack if you notice an error was possible when adding code.

Cool that the low-level configuration system and settings management tool of GNOME 3 gets its own conference!

https://en.wikipedia.org/wiki/Dconf

Because of stuff like ADL, the declaration order matters, thus I don't expect anyone ever submitting a paper to fix that.

And even if that isn't a problem, given how ISO works, someone still needs to get that paper in and voted.

As someone who has been using D since about late 2024, I enjoy the following things about it:

  - It has a type system that catches most category errors, without having to think too much about types
  - It is quite easy to read and write, and code in it has a high signal to noise ratio 
  - It provides a GC, but also allows you to write idiomatic code that doesn't allocate a lot (missing from a lot of gc languages, it feels like most GC languages force you to allocate more for every abstraction you write)
  - It supports GC style code for things that don't need to be efficient (>98% of the code I actually write)
  - I can easily micro-optimize the inner-loop code that does need to be efficient, without having to switch languages or setup ffi. I can also be relatively certain that the GC isn't firing too often in those loops, since the gc only collects when you gc-allocate
  - I can use all of the native libraries with C bindings on my system, with practically zero costs for bindings
  - Metaprogramming in it is top notch, I feel like every time I needed to do some type level shenanigans, I could do so in a way that actually looked like code in the end, without needing to maintain a code-generator. The way the metaprogramming works also stays fairly readable, it's not like macro_rules! or #defines or templates.

Overall, it has superseded C for pretty much everything I previously used C for, and is a joy to use for a lot of other usecases as well, I've found myself reaching for it for programs that I would otherwise write in python recently. Only major weakness in my daily experience is that you can't compile it to WASM, so I'm still using rust for that. I've considered learning Zig or Odin, but I feel like I would miss the GC for simple tasks, and D is good enough on most axes that I stopped looking for a new one true programming language to write all my code in.

Upstream has followed several of opend's innovations: we shipped interpolated expressions on day one of the fork (that was the straw that broke the camel's back) and then, after 7 years of procrastination, upstream also merged it a week later. We shipped extern(Objective-C) support, upstream backported it (and actually fixed enough bugs that I replaced my original impl with their's) a few months later. Upstream has talked about "safe by default" for over nine years. We shipped "safer by default" as a compromise (full safe by default is too much of a breaking change) a few months after forking, then a few months after we shipped it, upstream announced their own "safer by default" switch (which you have to opt into, so they kinda missed the point of "by default" but still, they followed the overall concept). For basically ever, Walter has said null checks in the language were a hard no, we implemented them and then.... guess what, a few months later, my implementation was backported (and again, a few bugs fixed so i appreciate the collaboration when we can get it) and walter decided to allow the merge. Opend shipped druntime on webassembly, looks like something similar coming to upstream. We merged the tuple destructuring PR (that was open for years again so the author was happy to get it to land somewhere!) and upstream followed there too.

There's a lot of smaller things that haven't been pulled though, like i merged a bug fix to module naming, which was an upstream PR from like 2018, a fix on library file name generation, a regression from 2019 but has a trivial workaround, a fix to redefined reflection names which everyone finds annoying, the implementation was written in 2017, but they had endless debates about syntax and i just made an executive decision and moved on but they still bikeshed... stuff like that, they're all little things but minor annoyances every time you hit them and the fixes were easy, so just do it!

Then the two bigger things I did they have talked about but probably won't do is i made the class monitor opt-in, this is a relatively big breaking change, I had to do fixes on 8 different projects. Each one took a few minutes, so not a huge deal, but still. They talked about this in an upstream meeting but decided against taking it (for now at least).

And then I changed the default init of all built in types to zero, including char and float, and this is controversial since float init to nan has legitimate advantages, and the breakage can be subtle if you don't catch it. I was on the fence personally, it more like a 51-49 vote rather than an obvious bug fix, but it is easier to explain to newbies that int and float both init to 0. In theory, you are supposed to explicitly initialize all these all the time, but in practice we know it is different.

So I think the competitive edge is pushing them a little. And I'm not anti-collaboration; I write blogs about my implementations with the hope that they'll give a little code review and that's been semi-successful, like the upstream backporters have indeed fixed bugs in my implementations so I'm happy to share back and forth, we both win that way.