digitalmars.D - PhobosV3+ Fundamental Elements
- Richard (Rikki) Andrew Cattermole (102/102) Aug 27 The following document is a collaboration between Adam Wilson and
- monkyyy (3/16) Aug 27 will structs be able to swap to a different rootclass?
- Richard (Rikki) Andrew Cattermole (2/21) Aug 27 Structs don't have a root class.
- Kapendev (20/45) Aug 29 Random thought: it would be nice if there could be an "IO layer"
- Dejan Lekic (11/26) Aug 30 +1
- Basile B. (4/9) Sep 01 To be honest I'm 100% sure that would not have changed my life
- Dejan Lekic (4/7) Sep 04 Then you are a bot. :) Joke aside, I believe you can navigate to
- Basile B. (8/15) Sep 09 No that trick does not work.I'm sorry about the way I bring this
- monkyyy (4/20) Sep 09 I think it may make sense to swap to the open source github
- Basile B. (5/26) Sep 09 so you think about the D org ? I've been very explicit about this
- Dejan Lekic (5/12) Sep 10 They are aggressively fighting gazillion LLM crawlers... They
- Steven Schveighoffer (14/32) Aug 30 I fully disagree with this. Templates are way way better. I don't
- Richard (Rikki) Andrew Cattermole (2/7) Aug 30 You need to talk with Adam.
- monkyyy (3/4) Aug 30 dogma
- libxmoc (24/60) Aug 30 C# doesn't have templates, so naturally Phobos v3 won't have
- monkyyy (5/10) Aug 30 Making it simpler would worsen the error messages; but if the
- Alexandru Ermicioi (6/9) Aug 31 It would still be good if they can be shipped as part of compiler
- Richard (Rikki) Andrew Cattermole (8/17) Aug 31 Yes, most of PhobosV3 functionality is going to have to be split out
- Adam Wilson (3/5) Sep 01 This is precisely it. We're not removing templates. We're just
- Walter Bright (8/8) Sep 07 One issue with templates is bloat resulting from:
- Max Klyga (10/20) Sep 02 Please don't do this. Not like this 🤦
- IchorDev (2/5) Sep 07 Couldn’t have said it better myself.
- Walter Bright (3/5) Sep 07 I've been slowly moving the dmd implementation towards sinks. Sinks can ...
- monkyyy (9/15) Sep 07 Templates will let it be inlined; naive delegates of strings;
- Richard (Rikki) Andrew Cattermole (6/12) Sep 08 Note that what Walter said here has nothing to do with delegates.
- monkyyy (5/19) Sep 08 surely walter knows the community wont accept printf... right?
- Richard (Rikki) Andrew Cattermole (5/27) Sep 08 That is what dmd uses.
- Walter Bright (2/11) Sep 10 https://github.com/dlang/dmd/blob/master/compiler/src/dmd/tokens.d#L976
- Richard (Rikki) Andrew Cattermole (2/14) Sep 10 https://github.com/dlang/dmd/pulls?q=is%3Apr+state%3Aclosed+ErrorSink
- Mindy Batek (0xEAB) (2/3) Sep 10 That’s where the attribute soup comes in and spoils it.
- Gregor =?UTF-8?B?TcO8Y2ts?= (9/14) Sep 18 Please include an option to have all these libraries statically
- Richard (Rikki) Andrew Cattermole (14/28) Sep 18 If you hit a wall like that you can always build it yourself.
- Sebastiaan Koppe (3/10) Sep 18 What is the issue with static libs?
- Richard (Rikki) Andrew Cattermole (9/21) Sep 18 The primary issue is you lose ability to load shared libraries that
- libxmoc (9/32) Sep 18 Just ship source code, I see 0 valid reasons to go with shared
- monkyyy (5/33) Sep 18 ssl and malloc should probably still be shared
- Gregor =?UTF-8?B?TcO8Y2ts?= (7/18) Sep 19 I'm not arguing against supporting shared linkage or having it as
- Richard (Rikki) Andrew Cattermole (6/31) Sep 19 I'm not arguing for the default. Nor am I arguing for druntime and base
- Gregor =?UTF-8?B?TcO8Y2ts?= (8/20) Sep 19 OK, this clears up a lot. The passage I quoted from your original
- Sebastiaan Koppe (3/19) Sep 19 We had this challenge at Symmetry, it's entirely solvable.
- Adam Wilson (11/12) Sep 19 What works for a private codebase at a private company that
- Gregor =?UTF-8?B?TcO8Y2ts?= (22/34) Sep 19 What should I build myself? I think your statement is a bit
- Richard (Rikki) Andrew Cattermole (13/53) Sep 19 The libraries that we ship that are built on top of the base PhobosV3
- Gregor =?UTF-8?B?TcO8Y2ts?= (21/32) Sep 19 The presence of a different version of a library in the same
- Richard (Rikki) Andrew Cattermole (6/24) Sep 19 Yes I am aware.
- Gregor =?UTF-8?B?TcO8Y2ts?= (21/32) Sep 19 The presence of a different version of a library in the same
- Larry Hemsley (4/123) Sep 18 I was just wondering how does a person signup to help with this project....
- Richard (Rikki) Andrew Cattermole (3/6) Sep 18 You send this to me privately as well, and has received a reply there.
The following document is a collaboration between Adam Wilson and
Richard (Rikki) Andrew Cattermole.
The PhobosV3+ work, is comprised of multiple components.
The first of these is ``based``, this is a low level component
that comprises of target specific elements to druntime, druntime
is the platform specific elements and may contain target
independent code.
The PhobosV2 replacement elements comprises of a base library,
and auxiliary libraries built on top.
```
GUI toolkit | web service framework
--------------------------------------------------
Event loop/windowing
--------------------------------------------------
PhobosV3 base
--------------------------------------------------
druntime
--------------------------------------------------
based
```
Each of the auxiliary libraries are shipped as a shared library
and D files suitable for importation using ``-extI`` switch.
The base library will be shipped as both a shared library and a
static library, along with the D files suitable for importation
using both ``-extI`` and ``-I``.
You will not need to deal with this, compiler support will exist
to aid and automate both the linking against these libraries
(including dependencies), as well as picking the right import
switch to use.
This is a non-negotiable aspect of the design, PhobosV3+ is
designed to have a very large scope, and be a batteries inclusive
standard library that solves all resonably common problems. This
cannot fit inside a single shared library nor should it. Most
people will not need access to most of what will be on offer for
every program. This is a standard approach to the problem in
application VM's such as .net.
One of the key design elements that is wanted, is to remove the
requirement for templates where possible. Templates are
expensive, especially if they are not needed to solve a problem.
A notable example of this is the dispatch and handling of
formatting to a string. There is unfortunately only one really
good solution that has been come up with to date, and that is a
single type that can be used for composition. It is also
important for use cases like pretty printing to support removal
of text, not just appending. The solution to this is to introduce
To format a type using such a string builder would require the
following signature for the hook method:
```d
struct Type {
void toString(scope StringBuilder) scope const;
}
```
This can then be taken as a pointer to with the usage of a
delegate to get a templateless dispatch call that doesn't care
about the types involves. The alternative to this is to use D
style variadics, and lean heavily into TypeInfo and reflection
capabilities. Luckily we are missing the reflection capabilities
to do this. A way to solve this would be added, a new function
pointer that each TypeInfo would store, this function would take
the value and do whatever reflection required to print it.
Absolutely horrid compared to this much simpler approach.
The string builder will need to be in druntime not based as it
will be using the GC for memory management, but this leads to
another set of problems, what to do about classes?
The ``Object`` root class is not the future for D, BUT we don't
have to break the world to resolve this problem. Instead we can
introduce a new feature called custom root classes. This will
allow us to define a new root class that can be swapped to being
the default in an edition.
What do I mean by 'swap to'? Two things, first the default parent
for classes will change to this new root class; second interfaces
will gain a class parent and the default will be the new one. But
you can change it like you could with the class.
```d
class MyRoot : void {
// Look its completely empty!
// No monitor, no methods, nothing!
}
interface MyInterface : MyRoot {
}
interface AnotherInterface : Object {
}
```
The current thinking would suggest that a new default root class
should appear similar to:
```d
class RootClass : void {
// No monitor
void toString(scope StringBuilder) scope const {}
ulong toHash() const => 0
int opCmp(scope const RootClass) scope const => 0;
}
```
But it won't be the only root class, PhobosV3+ will have more
than just this one.
In multithreading scenarios you will likely want one with a
monitor, and a message passing one specifically for windowing.
None of this is final, but it has been the general direction that
me and Adam have come up with over the last couple of years.
I'd like to thank monkyyy for giving me the motivation to get
this previously WIP article out.
Aug 27
On Thursday, 27 August 2026 at 22:39:04 UTC, Richard (Rikki)
Andrew Cattermole wrote:
The current thinking would suggest that a new default root
class should appear similar to:
```d
class RootClass : void {
// No monitor
void toString(scope StringBuilder) scope const {}
ulong toHash() const => 0
int opCmp(scope const RootClass) scope const => 0;
}
```
But it won't be the only root class, PhobosV3+ will have more
than just this one.
will structs be able to swap to a different rootclass?
Aug 27
"Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> On 28/08/2026 11:55 AM, monkyyy wrote:On Thursday, 27 August 2026 at 22:39:04 UTC, Richard (Rikki) Andrew Cattermole wrote:Structs don't have a root class.The current thinking would suggest that a new default root class should appear similar to: ```d class RootClass : void {     // No monitor     void toString(scope StringBuilder) scope const {}     ulong toHash() const => 0     int opCmp(scope const RootClass) scope const => 0; } ``` But it won't be the only root class, PhobosV3+ will have more than just this one.will structs be able to swap to a different rootclass?
Aug 27
On Thursday, 27 August 2026 at 22:39:04 UTC, Richard (Rikki) Andrew Cattermole wrote:The following document is a collaboration between Adam Wilson and Richard (Rikki) Andrew Cattermole. The PhobosV3+ work, is comprised of multiple components. The first of these is ``based``, this is a low level component that comprises of target specific elements to druntime, druntime is the platform specific elements and may contain target independent code. The PhobosV2 replacement elements comprises of a base library, and auxiliary libraries built on top. ``` GUI toolkit | web service framework -------------------------------------------------- Event loop/windowing -------------------------------------------------- PhobosV3 base -------------------------------------------------- druntime -------------------------------------------------- based ```Random thought: it would be nice if there could be an "IO layer" or something that abstracts over system libraries. Something to keep the Phobos part pure D in a way. Phobos currently tends to call some system libraries directly, for example. This is probably what BASED might be based on the "target specific elements" comment? Also, when I say IO layer, I don't mean what the Zig guys are doing with passing a vtable around at runtime. Just a basic compile-time abstraction layer.One of the key design elements that is wanted, is to remove the requirement for templates where possible. Templates are expensive, especially if they are not needed to solve a problem.It's easy to go crazy with compile-time stuff in any language really, from what I have seen. Just a guide like "start with no templates or generics and then maybe" could help a lot. Same guide should apply to RTTI related things, if that will be a thing. Both RTTI and templates add complexity that make code harder to read or document. ---To add or not to add? Umm, I only have one life and templates are fun anyway - Monkyyy
Aug 29
On Sunday, 30 August 2026 at 04:30:41 UTC, Kapendev wrote:+1 I can't wait for the actively supported event loop, endorsed by the DLF, built on top of PhobosV3 (or druntime, depending on some goals). Until that happens I baked my own and here is the architecture: https://codeberg.org/ddn/eve/src/branch/main/doc/EVE.md#2-architecture-overview I will probably never implement anything in layer 4 as it is not why i needed Eve... Speaking of Eve - if anyone is interested, I suggest reading [The Book of EVE](https://codeberg.org/ddn/eve/src/branch/main/The%20Book%20of%20EVE.md)The PhobosV2 replacement elements comprises of a base library, and auxiliary libraries built on top. ``` GUI toolkit | web service framework -------------------------------------------------- Event loop/windowing -------------------------------------------------- PhobosV3 base -------------------------------------------------- druntime -------------------------------------------------- based ```
Aug 30
On Sunday, 30 August 2026 at 10:54:58 UTC, Dejan Lekic wrote:[...] I will probably never implement anything in layer 4 as it is not why i needed Eve... Speaking of Eve - if anyone is interested, I suggest reading [The Book of EVE](https://codeberg.org/ddn/eve/src/branch/main/The%20Book%20of%20EVE.md)To be honest I'm 100% sure that would not have changed my life but I wanted to put an eye on this and actually codeberg blocks me : "Access denied".
Sep 01
On Tuesday, 1 September 2026 at 23:09:06 UTC, Basile B. wrote:To be honest I'm 100% sure that would not have changed my life but I wanted to put an eye on this and actually codeberg blocks me : "Access denied".Then you are a bot. :) Joke aside, I believe you can navigate to that document if you just go to https://codeberg.org/ddn/eve and then click on the `The Book of EVE.md` file.
Sep 04
On Friday, 4 September 2026 at 07:50:46 UTC, Dejan Lekic wrote:On Tuesday, 1 September 2026 at 23:09:06 UTC, Basile B. wrote:No that trick does not work.I'm sorry about the way I bring this off topic "topic" but that's actually serious. Whenever someone speeks about codeberg I try to rise this issue. Also tried to rise the topic on [HN](https://news.ycombinator.com/item?id=49064182). They put a kind of user-agent filtering in prod. You see I just try to get feedback every times someones mentions codeberg.To be honest I'm 100% sure that would not have changed my life but I wanted to put an eye on this and actually codeberg blocks me : "Access denied".Then you are a bot. :) Joke aside, I believe you can navigate to that document if you just go to https://codeberg.org/ddn/eve and then click on the `The Book of EVE.md` file.
Sep 09
On Wednesday, 9 September 2026 at 09:13:05 UTC, Basile B. wrote:On Friday, 4 September 2026 at 07:50:46 UTC, Dejan Lekic wrote:I think it may make sense to swap to the open source github software but not codeberg their politics seems dubious and the software isnt theirsOn Tuesday, 1 September 2026 at 23:09:06 UTC, Basile B. wrote:No that trick does not work.I'm sorry about the way I bring this off topic "topic" but that's actually serious. Whenever someone speeks about codeberg I try to rise this issue. Also tried to rise the topic on [HN](https://news.ycombinator.com/item?id=49064182). They put a kind of user-agent filtering in prod. You see I just try to get feedback every times someones mentions codeberg.[...]Then you are a bot. :) Joke aside, I believe you can navigate to that document if you just go to https://codeberg.org/ddn/eve and then click on the `The Book of EVE.md` file.
Sep 09
On Wednesday, 9 September 2026 at 18:53:16 UTC, monkyyy wrote:On Wednesday, 9 September 2026 at 09:13:05 UTC, Basile B. wrote:so you think about the D org ? I've been very explicit about this off-topic. This has nothing to do with the D org. I just try to see if anyone else experiments the [same problem](https://i.imgur.com/5deizmK.png).On Friday, 4 September 2026 at 07:50:46 UTC, Dejan Lekic wrote:I think it may make sense to swap to the open source github software but not codeberg their politics seems dubious and the software isnt theirsOn Tuesday, 1 September 2026 at 23:09:06 UTC, Basile B. wrote:No that trick does not work.I'm sorry about the way I bring this off topic "topic" but that's actually serious. Whenever someone speeks about codeberg I try to rise this issue. Also tried to rise the topic on [HN](https://news.ycombinator.com/item?id=49064182). They put a kind of user-agent filtering in prod. You see I just try to get feedback every times someones mentions codeberg.[...]Then you are a bot. :) Joke aside, I believe you can navigate to that document if you just go to https://codeberg.org/ddn/eve and then click on the `The Book of EVE.md` file.
Sep 09
On Thursday, 10 September 2026 at 03:16:23 UTC, Basile B. wrote:On Wednesday, 9 September 2026 at 18:53:16 UTC, monkyyy wrote:being on topic doesn't matter, the topic is walter trying and failing to convince everyone he made the right call on float.init for the 4000th time Github is declining, the alternatives should be criticized before theres a complete swap. Codeberg has worked perfectly for me, thats all the more reason to hear about it failing for someone else.On Wednesday, 9 September 2026 at 09:13:05 UTC, Basile B. wrote:so you think about the D org ? I've been very explicit about this off-topic. This has nothing to do with the D org. I just try to see if anyone else experiments the [same problem](https://i.imgur.com/5deizmK.png).On Friday, 4 September 2026 at 07:50:46 UTC, Dejan Lekic wrote:I think it may make sense to swap to the open source github software but not codeberg their politics seems dubious and the software isnt theirsOn Tuesday, 1 September 2026 at 23:09:06 UTC, Basile B. wrote:No that trick does not work.I'm sorry about the way I bring this off topic "topic" but that's actually serious. Whenever someone speeks about codeberg I try to rise this issue. Also tried to rise the topic on [HN](https://news.ycombinator.com/item?id=49064182). They put a kind of user-agent filtering in prod. You see I just try to get feedback every times someones mentions codeberg.[...]Then you are a bot. :) Joke aside, I believe you can navigate to that document if you just go to https://codeberg.org/ddn/eve and then click on the `The Book of EVE.md` file.
Sep 09
On Thursday, 10 September 2026 at 04:17:54 UTC, monkyyy wrote:On Thursday, 10 September 2026 at 03:16:23 UTC, Basile B. wrote:you dont realize how concerning is this. On gitlab I've boostraped styx about 150 times.Imagine one day they just block you with 'Access Denied'. Four years of work wasted.On Wednesday, 9 September 2026 at 18:53:16 UTC, monkyyy wrote:being on topic doesn't matter, the topic is walter trying and failing to convince everyone he made the right call on float.init for the 4000th time Github is declining, the alternatives should be criticized before theres a complete swap. Codeberg has worked perfectly for me, thats all the more reason to hear about it failing for someone else.[...]so you think about the D org ? I've been very explicit about this off-topic. This has nothing to do with the D org. I just try to see if anyone else experiments the [same problem](https://i.imgur.com/5deizmK.png).
Sep 09
On Wednesday, 9 September 2026 at 09:13:05 UTC, Basile B. wrote:No that trick does not work.I'm sorry about the way I bring this off topic "topic" but that's actually serious. Whenever someone speeks about codeberg I try to rise this issue. Also tried to rise the topic on [HN](https://news.ycombinator.com/item?id=49064182). They put a kind of user-agent filtering in prod. You see I just try to get feedback every times someones mentions codeberg.They are aggressively fighting gazillion LLM crawlers... They have to, as they do not have billions of dollars invested in infrastructure like GitHub and/or GitLab. Codeberg is a non-profit organisation.
Sep 10
On Thursday, 27 August 2026 at 22:39:04 UTC, Richard (Rikki)
Andrew Cattermole wrote:
One of the key design elements that is wanted, is to remove the
requirement for templates where possible. Templates are
expensive, especially if they are not needed to solve a problem.
A notable example of this is the dispatch and handling of
formatting to a string. There is unfortunately only one really
good solution that has been come up with to date, and that is a
single type that can be used for composition. It is also
important for use cases like pretty printing to support removal
of text, not just appending. The solution to this is to
templated.
To format a type using such a string builder would require the
following signature for the hook method:
```d
struct Type {
void toString(scope StringBuilder) scope const;
}
```
I fully disagree with this. Templates are way way better. I don't
want to build strings, I want to have a type add itself to a
string stream. I want that stream to be defined however you wish,
and compile down to the fastest code possible. It could just
build a string if that's what you want.
The place where this breaks down is virtual interfaces. But we
have a way to do this, already shown in
[Throwable.toString](https://dlang.org/phobos/object.html#.Throwable.toString.2).
Is there a place where this discussion is happening other than
the forum? Why are we deciding to move away from templates? Why
do you consider them expensive, is it just the compile time?
-Steve
Aug 30
On 30/08/2026 10:10 PM, Steven Schveighoffer wrote:Is there a place where this discussion is happening other than the forum? Why are we deciding to move away from templates? Why do you consider them expensive, is it just the compile time? -SteveYou need to talk with Adam.
Aug 30
On Sunday, 30 August 2026 at 10:10:21 UTC, Steven Schveighoffer wrote:Why are we deciding to move away from templates?dogma
Aug 30
On Sunday, 30 August 2026 at 10:10:21 UTC, Steven Schveighoffer wrote:On Thursday, 27 August 2026 at 22:39:04 UTC, Richard (Rikki) Andrew Cattermole wrote:templates either :^) (/s) Jokes aside, I think you are both touching on real problems from opposite angles. The issue with Phobos v2 is not templates, it's it was that they were abused to death. Every other function was a template, for "problems" that didn't need them, leading to: - Massive code bloat and binary sizes - Compilation times that grow exponentially, visible just by importing std - Error messages that require a PhD in template metaprogramming to decipher I also agree with on the toString, D doesn't have the luxury that As for Phobos v3 itself, I am personally skeptical, I fail to see what problem it tries to solve other than template bloat. I personally think D doesn't need phobos at all, it would be better split and proposed as dub packages, leaving just a base D that's good enough to get going and port to other platforms. I'd like to see druntime v2 (without libc/EH/GC and with a unified allocator API), than a phobos v3.One of the key design elements that is wanted, is to remove the requirement for templates where possible. Templates are expensive, especially if they are not needed to solve a problem. A notable example of this is the dispatch and handling of formatting to a string. There is unfortunately only one really good solution that has been come up with to date, and that is a single type that can be used for composition. It is also important for use cases like pretty printing to support removal of text, not just appending. The solution to this is templated. To format a type using such a string builder would require the following signature for the hook method: ```d struct Type { void toString(scope StringBuilder) scope const; } ```I fully disagree with this. Templates are way way better. I don't want to build strings, I want to have a type add itself to a string stream. I want that stream to be defined however you wish, and compile down to the fastest code possible. It could just build a string if that's what you want. The place where this breaks down is virtual interfaces. But we have a way to do this, already shown in [Throwable.toString](https://dlang.org/phobos/object.html#.Throwable.toString.2). Is there a place where this discussion is happening other than the forum? Why are we deciding to move away from templates? Why do you consider them expensive, is it just the compile time? -Steve
Aug 30
On Sunday, 30 August 2026 at 17:58:35 UTC, libxmoc wrote:The issue with Phobos v2 is not templates, it's it was that they were abused to death.- Error messages that require a PhD in template metaprogramming to decipherMaking it simpler would worsen the error messages; but if the function is 5 lines rather then 1000, it would be easier to understand. Template metaprogramming fundamentally produces bad error messages, we need to accept that and move on to simplistity.
Aug 30
On Sunday, 30 August 2026 at 17:58:35 UTC, libxmoc wrote:I personally think D doesn't need phobos at all, it would be better split and proposed as dub packages, leaving just a base D that's good enough to get going and port to other platforms.It would still be good if they can be shipped as part of compiler install or as extra packages in os repositories, for scripting convenience. Then on bigger project, they could be overriden with explicit dub versions.
Aug 31
On 01/09/2026 12:28 AM, Alexandru Ermicioi wrote:On Sunday, 30 August 2026 at 17:58:35 UTC, libxmoc wrote:Yes, most of PhobosV3 functionality is going to have to be split out into separate shared libraries built on top of the default linked against library. For that we need a bundle system to be able to handle the linking. In doing so we'd be shipping it all. If you want to use dub to pick different versions you'd be free to since all this optional stuff is opt-in.I personally think D doesn't need phobos at all, it would be better split and proposed as dub packages, leaving just a base D that's good enough to get going and port to other platforms.It would still be good if they can be shipped as part of compiler install or as extra packages in os repositories, for scripting convenience. Then on bigger project, they could be overriden with explicit dub versions.
Aug 31
On Monday, 31 August 2026 at 13:16:54 UTC, Richard (Rikki) Andrew Cattermole wrote:On 01/09/2026 12:28 AM, Alexandru Ermicioi wrote:shared libraries? Why? This is IMO unnecessary complexity. They should be shared as source. This will force maintainers to have good hygiene and keep build time quick.On Sunday, 30 August 2026 at 17:58:35 UTC, libxmoc wrote:Yes, most of PhobosV3 functionality is going to have to be split out into separate shared libraries built on top of the default linked against library. For that we need a bundle system to be able to handle the linking. In doing so we'd be shipping it all. If you want to use dub to pick different versions you'd be free to since all this optional stuff is opt-in.I personally think D doesn't need phobos at all, it would be better split and proposed as dub packages, leaving just a base D that's good enough to get going and port to other platforms.It would still be good if they can be shipped as part of compiler install or as extra packages in os repositories, for scripting convenience. Then on bigger project, they could be overriden with explicit dub versions.
Aug 31
On Monday, 31 August 2026 at 19:22:30 UTC, libxmoc wrote:Not sure about forcing. Poeple just do things sometimes, including making things slow to compile. I was going to make a joke about the enviroment, but it's too hot to think right now.Yes, most of PhobosV3 functionality is going to have to be split out into separate shared libraries built on top of the default linked against library. For that we need a bundle system to be able to handle the linking. In doing so we'd be shipping it all. If you want to use dub to pick different versions you'd be free to since all this optional stuff is opt-in.shared libraries? Why? This is IMO unnecessary complexity. They should be shared as source. This will force maintainers to have good hygiene and keep build time quick.
Aug 31
On Sunday, 30 August 2026 at 17:58:35 UTC, libxmoc wrote:The issue with Phobos v2 is not templates, it's it was that they were abused to death.This is precisely it. We're not removing templates. We're just not going to use them as much.
Sep 01
One issue with templates is bloat resulting from:
```d
string toString(T)(T v) { ... }
int i; s = toString(i);
byte b; t = toString(b);
```
Two different functions are generated, whereas only one is necessary. Integral
promotions are a highly useful way to reduce the amount of code generation.
Sep 07
On Thursday, 27 August 2026 at 22:39:04 UTC, Richard (Rikki)
Andrew Cattermole wrote:
...snip...
The solution to this is to introduce a string builder, similar
To format a type using such a string builder would require the
following signature for the hook method:
```d
struct Type {
void toString(scope StringBuilder) scope const;
}
```
Please don't do this. Not like this 🤦
This was discussed a million times and we have a existing
solutions to this (`std.algorithm.joiner`, `std.conv.text`,
`std.array.appender`)
Templates are just a fundamentally a better way of dealing with
this.
The correct way is to have a generic sink, not a string builder.
And especially not a specific string builder class implementation!
Sep 02
On Wednesday, 2 September 2026 at 13:17:35 UTC, Max Klyga wrote:The correct way is to have a generic sink, not a string builder. And especially not a specific string builder class implementation!Couldn’t have said it better myself.
Sep 07
On 9/2/2026 6:17 AM, Max Klyga wrote:The correct way is to have a generic sink, not a string builder. And especially not a specific string builder class implementation!I've been slowly moving the dmd implementation towards sinks. Sinks can be generic even without templates.
Sep 07
On Monday, 7 September 2026 at 23:30:42 UTC, Walter Bright wrote:On 9/2/2026 6:17 AM, Max Klyga wrote:Templates will let it be inlined; naive delegates of strings; handle 1 char, stack frame; 1 char, stack frame; 1 char, stack frame; etc. will be slow. There wont be a hope of the optimizer doing simd. Ascii processing should be a bunch of inline bitshift hacks; unicode and autodecoding and 3 different char types, wasnt good template code because it was 4 different type theories when theres only 2 that matter and the fastest one was painful to even use.The correct way is to have a generic sink, not a string builder. And especially not a specific string builder class implementation!I've been slowly moving the dmd implementation towards sinks. Sinks can be generic even without templates.
Sep 07
On 08/09/2026 11:30 AM, Walter Bright wrote:On 9/2/2026 6:17 AM, Max Klyga wrote:Note that what Walter said here has nothing to do with delegates. The sink is a class, ErrorSink. It uses varadics and printf style formatting. Which is a more closely tied to the string builder than the delegates being suggested here.The correct way is to have a generic sink, not a string builder. And especially not a specific string builder class implementation!I've been slowly moving the dmd implementation towards sinks. Sinks can be generic even without templates.
Sep 08
On Tuesday, 8 September 2026 at 07:32:05 UTC, Richard (Rikki) Andrew Cattermole wrote:On 08/09/2026 11:30 AM, Walter Bright wrote:surely walter knows the community wont accept printf... right? And typeinfo doesnt have enough info to introspect structs is the plan to change that, surely you need to print nested things?On 9/2/2026 6:17 AM, Max Klyga wrote:Note that what Walter said here has nothing to do with delegates. The sink is a class, ErrorSink. It uses varadics and printf style formatting. Which is a more closely tied to the string builder than the delegates being suggested here.The correct way is to have a generic sink, not a string builder. And especially not a specific string builder class implementation!I've been slowly moving the dmd implementation towards sinks. Sinks can be generic even without templates.
Sep 08
On 09/09/2026 4:18 AM, monkyyy wrote:On Tuesday, 8 September 2026 at 07:32:05 UTC, Richard (Rikki) Andrew Cattermole wrote:That is what dmd uses. Whereas with the string builder we can have a templated opOpAssign and use IES (if it supported formats) to do it. Templates are ok with this, and can be minimized over what std.format does.On 08/09/2026 11:30 AM, Walter Bright wrote:surely walter knows the community wont accept printf... right? And typeinfo doesnt have enough info to introspect structs is the plan to change that, surely you need to print nested things?On 9/2/2026 6:17 AM, Max Klyga wrote:Note that what Walter said here has nothing to do with delegates. The sink is a class, ErrorSink. It uses varadics and printf style formatting. Which is a more closely tied to the string builder than the delegates being suggested here.The correct way is to have a generic sink, not a string builder. And especially not a specific string builder class implementation!I've been slowly moving the dmd implementation towards sinks. Sinks can be generic even without templates.
Sep 08
On 9/8/2026 12:32 AM, Richard (Rikki) Andrew Cattermole wrote:On 08/09/2026 11:30 AM, Walter Bright wrote:https://github.com/dlang/dmd/blob/master/compiler/src/dmd/tokens.d#L976On 9/2/2026 6:17 AM, Max Klyga wrote:Note that what Walter said here has nothing to do with delegates.The correct way is to have a generic sink, not a string builder. And especially not a specific string builder class implementation!I've been slowly moving the dmd implementation towards sinks. Sinks can be generic even without templates.
Sep 10
On 11/09/2026 10:18 AM, Walter Bright wrote:On 9/8/2026 12:32 AM, Richard (Rikki) Andrew Cattermole wrote:https://github.com/dlang/dmd/pulls?q=is%3Apr+state%3Aclosed+ErrorSinkOn 08/09/2026 11:30 AM, Walter Bright wrote:https://github.com/dlang/dmd/blob/master/compiler/src/dmd/tokens.d#L976On 9/2/2026 6:17 AM, Max Klyga wrote:Note that what Walter said here has nothing to do with delegates.The correct way is to have a generic sink, not a string builder. And especially not a specific string builder class implementation!I've been slowly moving the dmd implementation towards sinks. Sinks can be generic even without templates.
Sep 10
On Thursday, 10 September 2026 at 22:30:07 UTC, Richard (Rikki) Andrew Cattermole wrote:On 11/09/2026 10:18 AM, Walter Bright wrote:https://gist.github.com/crazymonkyyy/577aefe66fda54e838b231434fdbdbf4https://github.com/dlang/dmd/blob/master/compiler/src/dmd/tokens.d#L976https://github.com/dlang/dmd/pulls?q=is%3Apr+state%3Aclosed+ErrorSink
Sep 10
On Thursday, 10 September 2026 at 23:23:20 UTC, monkyyy wrote:On Thursday, 10 September 2026 at 22:30:07 UTC, Richard (Rikki) Andrew Cattermole wrote:https://github.com/Kapendev/parin/blob/main/source%2Fparin%2Fjoka%2Fio.d#L64On 11/09/2026 10:18 AM, Walter Bright wrote:https://gist.github.com/crazymonkyyy/577aefe66fda54e838b231434fdbdbf4https://github.com/dlang/dmd/blob/master/compiler/src/dmd/tokens.d#L976https://github.com/dlang/dmd/pulls?q=is%3Apr+state%3Aclosed+ErrorSink
Sep 10
On Monday, 7 September 2026 at 23:30:42 UTC, Walter Bright wrote:Sinks can be generic even without templates.That’s where the attribute soup comes in and spoils it.
Sep 10
On Thursday, 27 August 2026 at 22:39:04 UTC, Richard (Rikki) Andrew Cattermole wrote:Each of the auxiliary libraries are shipped as a shared library and D files suitable for importation using ``-extI`` switch. The base library will be shipped as both a shared library and a static library, along with the D files suitable for importation using both ``-extI`` and ``-I``.Please include an option to have all these libraries statically linked as well. Sometimes, it just happens that one really, really needs a completely self-contained binary. Also, are there any remaining issues with D DLLs on Windows that may interfere with the shared library plan? I recall that there have been open issues for a long time, but I don't know how much is resolved now.
Sep 18
On 18/09/2026 7:16 PM, Gregor Mückl wrote:On Thursday, 27 August 2026 at 22:39:04 UTC, Richard (Rikki) Andrew Cattermole wrote:If you hit a wall like that you can always build it yourself. The libraries built on top of the base phobosv3 library, need to be shared libraries they are doing things like event loop that should not be available by default and are not going to work right if they were a static library. I don't want people who don't know what they are doing thinking that they should use a static library for easier shipping and then find themselves with core features not working.Each of the auxiliary libraries are shipped as a shared library and D files suitable for importation using ``-extI`` switch. The base library will be shipped as both a shared library and a static library, along with the D files suitable for importation using both ``-extI`` and ``-I``.Please include an option to have all these libraries statically linked as well. Sometimes, it just happens that one really, really needs a completely self-contained binary.Also, are there any remaining issues with D DLLs on Windows that may interfere with the shared library plan? I recall that there have been open issues for a long time, but I don't know how much is resolved now.Yes. TypeInfo needs to be per binary, Martin is currently upstreaming that. There are some parts of druntime that need upstreaming from ldc. And the installer needs updating to ship the shared libraries. But as far as -betterC is concerned, its working just fine.
Sep 18
On Friday, 18 September 2026 at 16:46:36 UTC, Richard (Rikki) Andrew Cattermole wrote:The libraries built on top of the base phobosv3 library, need to be shared libraries they are doing things like event loop that should not be available by default and are not going to work right if they were a static library. I don't want people who don't know what they are doing thinking that they should use a static library for easier shipping and then find themselves with core features not working.What is the issue with static libs?
Sep 18
On 19/09/2026 6:27 AM, Sebastiaan Koppe wrote:On Friday, 18 September 2026 at 16:46:36 UTC, Richard (Rikki) Andrew Cattermole wrote:The primary issue is you lose ability to load shared libraries that depend upon it. Which is an important feature of web servers, GUI toolkits and game engines. If you know and understand these limitations, building it yourself with dub shouldn't be an issue. Also we'll likely end up shipping libraries that would conflict if it were a static library. I have a couple of Luna's in mind as part of a GUI toolkit.The libraries built on top of the base phobosv3 library, need to be shared libraries they are doing things like event loop that should not be available by default and are not going to work right if they were a static library. I don't want people who don't know what they are doing thinking that they should use a static library for easier shipping and then find themselves with core features not working.What is the issue with static libs?
Sep 18
On Friday, 18 September 2026 at 18:33:41 UTC, Richard (Rikki) Andrew Cattermole wrote:On 19/09/2026 6:27 AM, Sebastiaan Koppe wrote:Just ship source code, I see 0 valid reasons to go with shared libraries. Let's not repeat dotnet's mistake of shipping programs with bazillions of dll's. They learned it the hard way when Go started to eat their lunch. They now brag about single static AOT executables in their marketing ;).On Friday, 18 September 2026 at 16:46:36 UTC, Richard (Rikki) Andrew Cattermole wrote:The primary issue is you lose ability to load shared libraries that depend upon it. Which is an important feature of web servers, GUI toolkits and game engines. If you know and understand these limitations, building it yourself with dub shouldn't be an issue. Also we'll likely end up shipping libraries that would conflict if it were a static library. I have a couple of Luna's in mind as part of a GUI toolkit.The libraries built on top of the base phobosv3 library, need to be shared libraries they are doing things like event loop that should not be available by default and are not going to work right if they were a static library. I don't want people who don't know what they are doing thinking that they should use a static library for easier shipping and then find themselves with core features not working.What is the issue with static libs?
Sep 18
On Friday, 18 September 2026 at 19:09:38 UTC, libxmoc wrote:On Friday, 18 September 2026 at 18:33:41 UTC, Richard (Rikki) Andrew Cattermole wrote:ssl and malloc should probably still be shared Im a little annoyed that raylib is shared but like opengl should be shared and unfortunately the gpu drivers in there infinite wisdom forces even worse trade offs on usOn 19/09/2026 6:27 AM, Sebastiaan Koppe wrote:Just ship source code, I see 0 valid reasons to go with shared libraries. Let's not repeat dotnet's mistake of shipping programs with bazillions of dll's. They learned it the hard way when Go started to eat their lunch. They now brag about single static AOT executables in their marketing ;).On Friday, 18 September 2026 at 16:46:36 UTC, Richard (Rikki) Andrew Cattermole wrote:The primary issue is you lose ability to load shared libraries that depend upon it. Which is an important feature of web servers, GUI toolkits and game engines. If you know and understand these limitations, building it yourself with dub shouldn't be an issue. Also we'll likely end up shipping libraries that would conflict if it were a static library. I have a couple of Luna's in mind as part of a GUI toolkit.[...]What is the issue with static libs?
Sep 18
On Friday, 18 September 2026 at 18:33:41 UTC, Richard (Rikki) Andrew Cattermole wrote:On 19/09/2026 6:27 AM, Sebastiaan Koppe wrote:I'm not arguing against supporting shared linkage or having it as a default. I'm only advocating for proper support for static linking as an alternative.What is the issue with static libs?The primary issue is you lose ability to load shared libraries that depend upon it. Which is an important feature of web servers, GUI toolkits and game engines.If you know and understand these limitations, building it yourself with dub shouldn't be an issue.Is this going to be a solid guarantee for Phobos 3?Also we'll likely end up shipping libraries that would conflict if it were a static library. I have a couple of Luna's in mind as part of a GUI toolkit.What is a "Luna"?
Sep 19
On 20/09/2026 6:13 AM, Gregor Mückl wrote:On Friday, 18 September 2026 at 18:33:41 UTC, Richard (Rikki) Andrew Cattermole wrote:I'm not arguing for the default. Nor am I arguing for druntime and base phobosv3 being shared alone.On 19/09/2026 6:27 AM, Sebastiaan Koppe wrote:I'm not arguing against supporting shared linkage or having it as a default. I'm only advocating for proper support for static linking as an alternative.What is the issue with static libs?The primary issue is you lose ability to load shared libraries that depend upon it. Which is an important feature of web servers, GUI toolkits and game engines.It is the current build procedures, and is intended to continue as far as I know.If you know and understand these limitations, building it yourself with dub shouldn't be an issue.Is this going to be a solid guarantee for Phobos 3?https://github.com/LunaTheFoxgirlAlso we'll likely end up shipping libraries that would conflict if it were a static library. I have a couple of Luna's in mind as part of a GUI toolkit.What is a "Luna"?
Sep 19
On Saturday, 19 September 2026 at 18:19:30 UTC, Richard (Rikki) Andrew Cattermole wrote:On 20/09/2026 6:13 AM, Gregor Mückl wrote:OK, this clears up a lot. The passage I quoted from your original post sounded as if shared would be the only supported option going forward. Having shared libraries as an option in addition to static linkage is an improvement that I welcome.I'm not arguing against supporting shared linkage or having it as a default. I'm only advocating for proper support for static linking as an alternative.I'm not arguing for the default. Nor am I arguing for druntime and base phobosv3 being shared alone.Oh, sorry. I misread your original sentence consistently for like 5 times. :(https://github.com/LunaTheFoxgirlAlso we'll likely end up shipping libraries that would conflict if it were a static library. I have a couple of Luna's in mind as part of a GUI toolkit.What is a "Luna"?
Sep 19
On Friday, 18 September 2026 at 18:33:41 UTC, Richard (Rikki) Andrew Cattermole wrote:On 19/09/2026 6:27 AM, Sebastiaan Koppe wrote:We had this challenge at Symmetry, it's entirely solvable.On Friday, 18 September 2026 at 16:46:36 UTC, Richard (Rikki) Andrew Cattermole wrote:The primary issue is you lose ability to load shared libraries that depend upon it.The libraries built on top of the base phobosv3 library, need to be shared libraries they are doing things like event loop that should not be available by default and are not going to work right if they were a static library. I don't want people who don't know what they are doing thinking that they should use a static library for easier shipping and then find themselves with core features not working.What is the issue with static libs?
Sep 19
On Saturday, 19 September 2026 at 20:32:17 UTC, Sebastiaan Koppe wrote:We had this challenge at Symmetry, it's entirely solvable.What works for a private codebase at a private company that publishes very little of it's codebase publicly will almost certainly fail when applied to a general purpose public ecosystem that lacks any of the guardrails that a private codebase has. Shared libraries are a fact of life and as a general purpose ecosystem we have to support them. Therefore, the components of the runtime and standard library that must be separated to function correctly with other shared libraries *must* be separated as such.
Sep 19
On Friday, 18 September 2026 at 16:46:36 UTC, Richard (Rikki) Andrew Cattermole wrote:On 18/09/2026 7:16 PM, Gregor Mückl wrote:What should I build myself? I think your statement is a bit ambiguous. Do you mean recompiling Phobos or building an entire competing standard library? I'm assuming the former.Please include an option to have all these libraries statically linked as well. Sometimes, it just happens that one really, really needs a completely self-contained binary.If you hit a wall like that you can always build it yourself.The libraries built on top of the base phobosv3 library, need to be shared libraries they are doing things like event loop that should not be available by default and are not going to work right if they were a static library.I don't understand the event loop part at all. This seems to come out of the blue. Can you give me a little more context on that?I don't want people who don't know what they are doing thinking that they should use a static library for easier shipping and then find themselves with core features not working.Well, a binary that needs to sit next to a bunch of libraries isn't such a great deal, either. I'm not against shared libraries as a default, but there must be a way to use at least the most common part of Phobos statically linked into a binary. There are quite a few use cases out there where people are expected to copy e.g. single Windows DLLs around to make things work (VST instruments, for example - so dplug would be impacted). Also, another scenario that I believe is full of nasty surprises is when two shared libraries get loaded dynamcially by a process at runtime that are built with different version of Phobos. Even if the file names don't collide, the symbol names will because they have to be exported. If Phobos was linked statically into each shared library with hidden symbol visiblity, those issues would go away.
Sep 19
On 20/09/2026 6:04 AM, Gregor Mückl wrote:On Friday, 18 September 2026 at 16:46:36 UTC, Richard (Rikki) Andrew Cattermole wrote:The libraries that we ship that are built on top of the base PhobosV3 library. PhobosV3 base library is akin to V2, we have no auxillary libraries built on top equivalent in V2.On 18/09/2026 7:16 PM, Gregor Mückl wrote:What should I build myself? I think your statement is a bit ambiguous. Do you mean recompiling Phobos or building an entire competing standard library? I'm assuming the former.Please include an option to have all these libraries statically linked as well. Sometimes, it just happens that one really, really needs a completely self-contained binary.If you hit a wall like that you can always build it yourself.Proper event loops are very expensive to just link in and have on. Background threads on mass, and lots of extra dependencies. Not a good default. But its necessary if you want to do windowing and networking properly.The libraries built on top of the base phobosv3 library, need to be shared libraries they are doing things like event loop that should not be available by default and are not going to work right if they were a static library.I don't understand the event loop part at all. This seems to come out of the blue. Can you give me a little more context on that?Yes, none of that is affected.I don't want people who don't know what they are doing thinking that they should use a static library for easier shipping and then find themselves with core features not working.Well, a binary that needs to sit next to a bunch of libraries isn't such a great deal, either. I'm not against shared libraries as a default, but there must be a way to use at least the most common part of Phobos statically linked into a binary. There are quite a few use cases out there where people are expected to copy e.g. single Windows DLLs around to make things work (VST instruments, for example - so dplug would be impacted).Also, another scenario that I believe is full of nasty surprises is when two shared libraries get loaded dynamcially by a process at runtime that are built with different version of Phobos. Even if the file names don't collide, the symbol names will because they have to be exported. If Phobos was linked statically into each shared library with hidden symbol visiblity, those issues would go away.Unless you are doing something more advanced build setup wise, you would also be using different compilers and druntimes too. That is not meant to work.
Sep 19
On Saturday, 19 September 2026 at 18:27:24 UTC, Richard (Rikki) Andrew Cattermole wrote:On 20/09/2026 6:04 AM, Gregor Mückl wrote:The presence of a different version of a library in the same process can be something that is completely out of the control of the affected developer. I can give you a few examples of how this kind of stuff can get really uncontrollable: - Vulkan specifies a dynamic loading scheme for layers that intercept API calls between the application and the driver. The landscape for these kinds of layers has evolved into a not quite lawless wild west. Drivers and a lot of applications that you would otherwise not expect ship layers that get loaded into *your* program's address space when you create a Vulkan instance. There's nothing you can do about that - the loader doesn't have an off switch for this behavior by design. Steam and OBS are examples for programs that ship such Vulkan layers. - Your product is a plugin for some big application like Word or Revit or Unity... you have no control over what those programs are going to load alongside your own plugin. These are definitely situations where the modules that get loaded need to be as self-contained and isolated as possible to try and avoid funky issues.Also, another scenario that I believe is full of nasty surprises is when two shared libraries get loaded dynamcially by a process at runtime that are built with different version of Phobos. Even if the file names don't collide, the symbol names will because they have to be exported. If Phobos was linked statically into each shared library with hidden symbol visiblity, those issues would go away.Unless you are doing something more advanced build setup wise, you would also be using different compilers and druntimes too. That is not meant to work.
Sep 19
On 20/09/2026 6:46 AM, Gregor Mückl wrote:On Saturday, 19 September 2026 at 18:27:24 UTC, Richard (Rikki) Andrew Cattermole wrote:Yes I am aware. You the developer working in this environment need to be aware of it and the default configuration for things like the eventloop or GC is not going to be appropriate. You need to make informed decisions and take the appropriate actions.On 20/09/2026 6:04 AM, Gregor Mückl wrote:The presence of a different version of a library in the same process can be something that is completely out of the control of the affected developer. I can give you a few examples of how this kind of stuff can get really uncontrollable:Also, another scenario that I believe is full of nasty surprises is when two shared libraries get loaded dynamcially by a process at runtime that are built with different version of Phobos. Even if the file names don't collide, the symbol names will because they have to be exported. If Phobos was linked statically into each shared library with hidden symbol visiblity, those issues would go away.Unless you are doing something more advanced build setup wise, you would also be using different compilers and druntimes too. That is not meant to work.
Sep 19
On Saturday, 19 September 2026 at 18:27:24 UTC, Richard (Rikki) Andrew Cattermole wrote:On 20/09/2026 6:04 AM, Gregor Mückl wrote:The presence of a different version of a library in the same process can be something that is completely out of the control of the affected developer. I can give you a few examples of how this kind of stuff can get really uncontrollable: - Vulkan specifies a dynamic loading scheme for layers that intercept API calls between the application and the driver. The landscape for these kinds of layers has evolved into a not quite lawless wild west. Drivers and a lot of applications that you would otherwise not expect ship layers that get loaded into *your* program's address space when you create a Vulkan instance. There's nothing you can do about that - the loader doesn't have an off switch for this behavior by design. Steam and OBS are examples for programs that ship such Vulkan layers. - Your product is a plugin for some big application like Word or Revit or Unity... you have no control over what those programs are going to load alongside your own plugin. These are definitely situations where the modules that get loaded need to be as self-contained and isolated as possible to try and avoid funky issues.Also, another scenario that I believe is full of nasty surprises is when two shared libraries get loaded dynamcially by a process at runtime that are built with different version of Phobos. Even if the file names don't collide, the symbol names will because they have to be exported. If Phobos was linked statically into each shared library with hidden symbol visiblity, those issues would go away.Unless you are doing something more advanced build setup wise, you would also be using different compilers and druntimes too. That is not meant to work.
Sep 19
On 8/27/26 4:39 PM, Richard (Rikki) Andrew Cattermole wrote:
The following document is a collaboration between Adam Wilson and
Richard (Rikki) Andrew Cattermole.
The PhobosV3+ work, is comprised of multiple components.
The first of these is ``based``, this is a low level component that
comprises of target specific elements to druntime, druntime is the
platform specific elements and may contain target independent code.
The PhobosV2 replacement elements comprises of a base library, and
auxiliary libraries built on top.
```
GUI toolkit        |      web service framework
--------------------------------------------------
           Event loop/windowing
--------------------------------------------------
             PhobosV3 base
--------------------------------------------------
                druntime
--------------------------------------------------
                 based
```
Each of the auxiliary libraries are shipped as a shared library and D
files suitable for importation using ``-extI`` switch.
The base library will be shipped as both a shared library and a static
library, along with the D files suitable for importation using both ``-
extI`` and ``-I``.
You will not need to deal with this, compiler support will exist to aid
and automate both the linking against these libraries (including
dependencies), as well as picking the right import switch to use.
This is a non-negotiable aspect of the design, PhobosV3+ is designed to
have a very large scope, and be a batteries inclusive standard library
that solves all resonably common problems. This cannot fit inside a
single shared library nor should it. Most people will not need access to
most of what will be on offer for every program. This is a standard
approach to the problem in application VM's such as .net.
One of the key design elements that is wanted, is to remove the
requirement for templates where possible. Templates are expensive,
especially if they are not needed to solve a problem.
A notable example of this is the dispatch and handling of formatting to
a string. There is unfortunately only one really good solution that has
been come up with to date, and that is a single type that can be used
for composition. It is also important for use cases like pretty printing
to support removal of text, not just appending. The solution to this is
To format a type using such a string builder would require the following
signature for the hook method:
```d
struct Type {
    void toString(scope StringBuilder) scope const;
}
```
This can then be taken as a pointer to with the usage of a delegate to
get a templateless dispatch call that doesn't care about the types
involves. The alternative to this is to use D style variadics, and lean
heavily into TypeInfo and reflection capabilities. Luckily we are
missing the reflection capabilities to do this. A way to solve this
would be added, a new function pointer that each TypeInfo would store,
this function would take the value and do whatever reflection required
to print it. Absolutely horrid compared to this much simpler approach.
The string builder will need to be in druntime not based as it will be
using the GC for memory management, but this leads to another set of
problems, what to do about classes?
The ``Object`` root class is not the future for D, BUT we don't have to
break the world to resolve this problem. Instead we can introduce a new
feature called custom root classes. This will allow us to define a new
root class that can be swapped to being the default in an edition.
What do I mean by 'swap to'? Two things, first the default parent for
classes will change to this new root class; second interfaces will gain
a class parent and the default will be the new one. But you can change
it like you could with the class.
```d
class MyRoot : void {
    // Look its completely empty!
    // No monitor, no methods, nothing!
}
interface MyInterface : MyRoot {
}
interface AnotherInterface : Object {
}
```
The current thinking would suggest that a new default root class should
appear similar to:
```d
class RootClass : void {
    // No monitor
    void toString(scope StringBuilder) scope const {}
    ulong toHash() const => 0
    int opCmp(scope const RootClass) scope const => 0;
}
```
But it won't be the only root class, PhobosV3+ will have more than just
this one.
In multithreading scenarios you will likely want one with a monitor, and
a message passing one specifically for windowing.
None of this is final, but it has been the general direction that me and
Adam have come up with over the last couple of years.
I'd like to thank monkyyy for giving me the motivation to get this
previously WIP article out.
I was just wondering how does a person signup to help with this project.
I was thinking to help with the based layer but could not find any place
on the github project page to signup.
Sep 18
On 19/09/2026 5:35 AM, Larry Hemsley wrote:I was just wondering how does a person signup to help with this project. I was thinking to help with the based layer but could not find any place on the github project page to signup.You send this to me privately as well, and has received a reply there. Talk to Adam Wilson on Discord.
Sep 18