DConf 2026 in London
dconf.org
dconf.org
Edit: I think it was called "Herbception"s after Herb Sutter, and it really sounded like a good idea to me
I used to be a big fan of C++ exceptions, but eventually soured on it for various reasons. Here's an article partially addressing it from a while back:
I would classify D's scope exit/failure/success as RAII actually, even if D uses a GC.
Sometimes you might not need exceptions and something like std::expected or optional is better.
In my case I use expected for some network APIs since I expect failures to happen out of my control aspart of the flow of my program, but I do not see why I would not use exceptions in many other situations, such as for non-ignorsble errors. I could think of a lack of disk space or some other fatal error thst is not under the control of the program.
If you forget to handle this, the error will cascade.
Also, exceptions do not make the signature of a function change (at least not in C++, Java checked exceptions is different). This means that the plasticity for adding errors at any depth of the call stack augments without bypassing any error silently.
All in all, I would say exceptions should be the main mechanism in normal circumstances and for expected errors you csn use error/result types.
It has better than that, but it is a bit clunky compared with C++(just use struct instead of class). You can have proper destructors, but if you have a container you need to be more careful than in C++.
In D exceptions are the default like in C++ and you have to opt out with nothrow or extern(C) or betterC.
Really try some D code in a bigger situation it is 90% good and almost worth using over C++, but if you can't have GC it is a huge pain, but better than C.
Also, recently the GC implementation received a big modernization upgrade.
D's scope exit/failure/success is built on top of RAII and has nothing to do with the GC.
> I would say exceptions should be the main mechanism in normal circumstances and for expected errors you csn use error/result types.
Come to DConf (or watch the live stream) and I hope I can change your mind, or at least challenge your conclusions!
What I meant here (I do not know the mechanism) is that I am aware that D has a GC. This means, correct me if I am wrong, that D does not use destructors (like C++) for scope exit/failure/success, though they are scoped mechanisms (RAII-like).
> Come to DConf (or watch the live stream)
I always follow D (even if I did not use it intensively). I have extremely high respect for you as a language designer and as a technician. Your knowledge is very refined, so I never take your opinions lightly.
Probably one of the most knowledgeable persons in the industry for native language design. However, I am far and cannot attend, so I will definitely watch it.
> or at least challenge your conclusions!
No problem in challenging them. I am always open to do things better. This is just my practical experience as I implement stuff so far.
I currently think exceptions seems like a good default mechanism (apparently at least) compared to alternatives. But I also think other mechanisms have their place and can/should be used even in the same program, just for different things.
All mechanisms have trade-offs. I just talked about defaults from my POV for the kind of software I develop (mostly server-side, some client-side, and not embedded in the extremely constrained sense).
-----------------------------
One question: I tried to use D several times in my career (20 years of C++ experience here, roughly). I found it a lot of fun. I like it better than more "modern languages". I like the plasticity D provides. But I am not sure how it would work if I want to do:
1. backend (server-side mainly, Linux is main platform, x86-64)
2. desktop + android and iOS (being mobile more important than desktop)
3. web assembly (even more important than mobile at this moment, could change).
4. backwards compatibility (heard complaints of versions breaking stuff frequently around).
5. interaction with C++.
It would be ready for all of the above? Also, very very handy would be to wrap C++ code and C code. I saw that D had an ongoing effort for C++ compatibility better than other languages, but I am afraid it could be half-broken. Even if it is, it is documented what works and what does not work? That would help a lot.
Thanks.
It does, but the user doesn't see them.
There are people working on 1, 2 and 3.
> 4. backwards compatibility (heard complaints of versions breaking stuff frequently around).
We listened, and cut way back on breaking changes. Now we have editions.
> 5. interaction with C++.
C++ has gotten to the point where it would take another decade of my time to wire in ImportC++. However, if you stick with C++'s C interface when interfacing with D, you should be fine. D will also work with C++ name mangling, but all the complexity of C++ templates and such is just too much.
And thank you for the kind words! I definitely appreciate it.
> I am far and cannot attend, so I will definitely watch it.
Wonderful!
There is a fork of D compiler called OpenD which has some WebAssembly support with garbage collection and standard library. I've used it, it works for the most part, but there's bugs and if you encounter any issues then you're on your own.
The C standard library works well with it.
I personally much prefer Rust style Result which also can't be ignored, and puts fallibili5y in the function signature.
In Java exceptions can be part of a method's declared type information, so handling is checked at compile time and IDEs can display the info.
Unfortunately certain Java missteps made this design unpopular these days. For example, for many years new String(bytes, "UTF-8"); made it mandatory to catch a UnsupportedEncodingException despite the language spec guaranteeing UTF-8 would be available. A later version of Java addressed it, but still...
Your code shouldn't need to make assumption about whether exception are being thrown or not.
Your mistake is thinking that a function potentially throwing means you need to catch it.
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.
But it enables incremental addition of errors and you can decide later what to do exactly, so I still tend to see it as an advantage.
It is like defer the error handling and centralize later.
If you want to handle an error in place immediately, prpbably it is not an exception what you want.
But if you need it is a fatal error, I do not see any harm, since the most you will do with that exception is to unwind and log or telemetry or whatever to tracke the errors.
Additionally, Khalil Estell has made an excellent work proving that the way exceptions are currently implemented is not optimal and there is plenty of room for improvement, when someone cares about their implementation.
"Cutting C++ Exception Time by +90%? - Khalil Estell - CppCon 2025"
In the end, it was DOA due to compiler architecture, so that was the end of that beautiful design.
I've had to accept result types is about as good as its going to get, all that is missing to make them nice is unwrapping support in if statements. Which I too have a proposal for and implemented it. But alas politics.
I can never get past the ugly syntax.
Standard exception handling is:
- Whenever an error happens, the program puts a description of it into an “exception” object. You go from the innermost dynamic scope to the outermost looking for handlers. Once you find a handler willing to accept that type of exception, you unwind to the point where it was installed then invoke it, passing the exception object.
Condition handling[3] is:
- Whenever an error happens, the program puts a description of it into a “condition” object. You go from the innermost dynamic scope to the outermost looking for handlers. Once you find a condition handler willing to accept that type of condition, you invoke it as a regular callback, without unwinding, passing the condition object.
- The handler then packs up some data into a “restart” object. You go through all the dynamic scopes again (remember that the erroring function is still active). Once you find a restart handling willing to accept this type of restart, you unwind to the point where it was installed then invoke it, passing the restart object.
(I am omitting things outside the happy path: a way for the exception/condition handler to punt, what happens if the condition handler does not invoke a restart, etc.)
As far as the benefits of this two-phase approach, Practical Common Lisp gives an example[4] of a single-record parser that raises an “invalid record” condition, a loop around it that installs a “skip to next record” restart, and finally the caller can make the policy decision on what to do for invalid records.
As another example, Common Lisp signals an “unbound-variable”[5] condition leaving the “use-value” and “store-value” restarts in scope, then the REPL installs a handler that offers them interactively. (My own half-serious example of a DOS abort/retry/fail prompt is in this vein too, chosen mostly because it feels strange that you can’t do it in a conventional exception system.)
[1] https://package.opendylan.org/dylan-programming-book/excepti...
[2] https://news.ycombinator.com/item?id=31196046
[3] https://www.nhplace.com/kent/Papers/Condition-Handling-2001....
[4] https://gigamonkeys.com/book/beyond-exception-handling-condi...
[5] https://www.lispworks.com/documentation/HyperSpec/Body/e_unb...
But the "I can never get past the ugly syntax." reason is unusually superficial from you. Understanding Lisp macros or CLOS (the very cool object system) or Conditions (which are like exceptions, but also different in a very interesting and powerful way) is totally worth enduring the syntax for a language designer.
If you find the time, give it a try! Either way: I am a big D fan, so I agree with your tastes most of the time. Thanks for your work :)
I find the ((()))) aspect of it difficult to read, whereas the algebraic notation is easy. I've struggled with trying to read Lisp code for decades. It's a proverbial square peg that won't fit in the round hole.
A major aspect of D is the aesthetic look of the code. It's why I call D "elegant" as it just looks good on the screen. For example, this is how modules are imported:
import foo;
By the way, big fan of D even though I don't get to use it much. Appreciate your work!
Edit: Also would be nice to adopt move and copy semantics even closer to C++ and maybe need less explicit moves, and ideally less mess with calling __xdtor when trying to do RAII
there's a contributor working with both upstream and opend adding wasi support as well, and he also got exception support working, we'll probably ship that next month.
so the full d story on wasm is progressing too.
You might say if it is so easy, why not do it upstream? It takes years of political arguments and random ghosting to get anything done up there, all while constant (regression inducing) code churn breaks your PRs every other month, so you spend 3x the time rebasing than you ever spent writing the implementation before it is merged...... if it ever gets merged at all. I have several successful contributions to upstream D, it happens, but most the work done there is ignored. You might get some encouraging forum replies, but when it comes time to ship it? Crickets. Several former D contributors jumped ship for Zig many years ago, and it was a real loss for us (and real gain for them).
With the opend, I know if it works and delivers real world value, I can ship a release, dmd and ldc together, so minimal duplicated waste work.
What should you use? idk, opend is basically my pet project, provided in the hope that it will be useful, but THIS SOFTWARE IS PROVIDED `'AS IS″ AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE so your mileage may vary. Still, I maintain about a half million lines of code, some of which is quite old, so keeping some stability is important to me while moving forward with select common-sense, incremental improvements. Most D code works fine either way though, I've done web programming a long time, in the old school tradition, so words like "progressive enhancement" and "graceful degradation" are meaningful to me, even when being a compiler maintainer.
Oof, yeah that is definitely a pain point. Not to get too personal, but why would you continue to invest so much time in the language if upstream isn't accommodating?
Has WalterBright had any comments on this? He usually is so vocal, any hope of a remerge of the OpenD changes in to CanonD?
Anyway, I appreciate you trying to advance Dlang, I fight for it all the time at work, and usually get to do stuff in it(I am old and have privileges).
Sunk cost fallacy lol. I got on the D train back in 2006 and of those half million lines of code I'm responsible for maintaining, about a quarter million are my own. A lot of work to make that... I have my own, from scratch: gui toolkit, terminal emulator, games, spreadsheet, web apps, shell, scriptable calculator, and more. Mostly mine but using libraries or ported third party code sometimes: music players, web browsers (one is from scratch but not terribly functional, one using chromimum libraries I'm typing this comment on right now), window manager, taskbar, the list goes on.
My whole daily work environment is made out of D code. And yeah, sure, there's alternatives, but I like mine. And a lot of it is making the apis cute. For example, I wanted to add a menu option to reset something in one of my programs last week. So I opened the code and wrote
``` @menu("&Query") @accelerator("Ctrl+R") void Load_Default() { query.content = readTextFile("default.txt"); variables.content = "{}"; } ```
It recompiled in about a second and a half and just like that, I can press ctrl+r to reload the defaults, or click Query -> Load Default in the menu (or alt+q and keyboard to it etc). My gui library takes care of a lot of things so I just write some functionality as-needed and use it a few seconds later.
Can I do that with Microsoft Excel? excel is a useful program too, but it takes longer to just load than it takes me to change the code, recompile, and relaunch my spreadsheet program lol.
Could I port all this stuff to other languages? Maybe. But it is less work to just maintain a stable fork of the compiler lol. (at the risk of getting flagged for being a troll again, I feel the same way about wayland... easier to maintain xorg, a program i haven't even restarted for years, than to rewrite the whole ecosystem.)
And that's the key point too, I do generally think the D language is mostly good enough as-is, so if I never committed another line of code to it, I'd still find it good enough. But it is nice if I do hit a language/compiler problem I can just fix it too.
You can find such @nogc collections in `dplug:core` or `nulib` packages.
> I would like to see Phobos 3 be more betterC forward.
It is, some part of it is going to be called BaseD and with a more restricted subset, without GC usage.
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.
My experience was the ldc impl was MUCH easier.... and optimizes much better, no surprise, but also compiled WAY slower. On dmd, the null checks barely affected compile speeds at all, but on ldc, the runtime impact isn't bad... but the compile time hit is ENORMOUS. I didn't even notice it at first, because I mostly use ldc just for cross compiles (another thing opend makes easy, `opend install xpack-win64` for example makes Windows builds just work, and it can do icons built in without third party toolchain as well, something hipreme took to upstream via his redub program that copied my implementation. he then added similar for Mac but I havent' pulled that back to opend yet, i will though) and I misdiagnosed.
Went looking for why the compile times were so much worse in opend ldc vs upstream (and btw note my definition of "so much worse" is like 3 seconds instead of 2 seconds, 50% is signifcant) and tried PGO and diffs in codegen and llvm versions...... then realized no, it is the null checks.
So the ldc implementation was easy and seems bug free (the bugs rikki fixed were in obscure corners of dmd's backend), and it optimizes well for runtime..... but wow it takes its sweet time to do that optimization. I'd appreciate someone else taking a look at that some day since there might be some better way to do it than I did (i basically copied the RangeError implementation on pointers for null check).
But I expect some day it'll come and then hopefully we'll make both of our compilers better.
but maybe this is the first step toward something more useful.
FYI that had very little to do with OpenD merging the tuple syntax - at least from my perspective - Timon may feel differently. I was the one who got the ball rolling on the DIP for it and kept pushing the process forward, and I also helped Timon and Nick get it over the finish line by fixing an ICE in the backend caused by destructuring a tuple of structs.
I've wanted first class tuple syntax in D since 2013, and when Timon mentioned not having time to do a DIP for it, I offered to help. It would've happened regardless of whether it got merged into OpenD or not.
int foo() { return bar(); }
int bar() { return 3; }It has deleterious consequences. One solution is to add a forward declaration, which is the kind of busywork a language is supposed to eliminate.
Another is to reverse the natural order of functions, with the implementation functions at the top and the interface of the module at the bottom.
After all, do you read a website from top to bottom or bottom to top?
So I guess I kind of prefer seeing helper functions at the top and the main logic at the bottom most of the time.
And even if that isn't a problem, given how ISO works, someone still needs to get that paper in and voted.
- 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.