Earlier quoted context omitted.
Ages ago in C++ there was the hope of having the standard library give more error codes and use error values instead of full exceptions. Zig has some excellent innovations in that direction, any hope of that in D? Edit: I think it was called "Herbception"s after Herb Sutter, and it really sounded like a good idea to me
It was the throwing values proposal. Bjarne was not satisfied with the proposal because it didn't interact well with existing exceptions code.
DConf 2026 in London
31–40 of 71 posts
Re: DConf 2026 in London
#32I haven't announced my keynote yet, but it's about various ways of handling errors and their tradeoffs. This has inspired some spirited debate in the D forums! I'm looking forward to engaging with everyone.
Ages ago in C++ there was the hope of having the standard library give more error codes and use error values instead of full exceptions. Zig has some excellent innovations in that direction, any hope of that in D? Edit: I think it was called "Herbception"s after Herb Sutter, and it really sounded like a good idea to me
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"
Re: DConf 2026 in London
#33Earlier quoted context omitted.
It's been a while since I looked at Zig. I couldn't say anything intelligent about it without some study. 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: https://dlang.org/articles/exception-safe.html
I think there is nothing better than exceptions + RAII for error handling since exceptions cannot be ignored by accident. 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 f…
I personally much prefer Rust style Result which also can't be ignored, and puts fallibili5y in the function signature.
Re: DConf 2026 in London
#34Earlier quoted context omitted.
Is it because bar is defined after foo?
Yes. 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?
Re: DConf 2026 in London
#35Earlier quoted context omitted.
I think there is nothing better than exceptions + RAII for error handling since exceptions cannot be ignored by accident. 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 f…
The worst thing about exceptions is that you can't tell from the type signature of a function whether it might throw one. So you have to hope it's documented, guess at whether try-catch is necessary, or reading through the entire call stack. 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...
Re: DConf 2026 in London
#36Earlier quoted context omitted.
> I would classify D's scope exit/failure/success as RAII actually, even if D uses a GC. 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 conc…
> D's scope exit/failure/success is built on top of RAII and has nothing to do with the GC. 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 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!
Re: DConf 2026 in London
#37Earlier quoted context omitted.
> I would classify D's scope exit/failure/success as RAII actually, even if D uses a GC. 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 conc…
> D's scope exit/failure/success is built on top of RAII and has nothing to do with the GC. 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…
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.
Re: DConf 2026 in London
#38I don't know why but dlang continues to draw me - I've really enjoyed many of the talks in the past
I always try it every few years, but I can never figure out how to get a good ide experience. I’ve tried both VSCode and IntelliJ. I most recently tried to make it work for advent of code last year. Maybe I’m just too used to how good the IDE experience for Java is?
Re: DConf 2026 in London
#39Earlier quoted context omitted.
it's an evolutionary (as opposed to revolutionary) language; it is in many ways a reimagining of c++ based on decades of observing the latter's flaws and weaknesses in the real world. if you're in the c or c++ ecosystem already you will likely find D a pleasant set of improvements to c++.
For example, C and C++ still cannot compile this: int foo() { return bar(); } int bar() { return 3; }
Re: DConf 2026 in London
#40Earlier quoted context omitted.
Going to include the common lisp condition system in the comparison?
I tried Lithp a couple times, but it never caught on with me. I wouldn't know what the best techniques for Lithp error handling would be. 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...