PhobosV3+ Fundamental Elements

[Larry Hemsley]

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 introduce a string builder, similar to C#'s that is not 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;
> }
> ```
> 
> 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.