www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D Language Foundation January 2023 Quarterly Meeting Summary

reply Mike Parker <aldacron gmail.com> writes:
The January meeting took place on January 13th at 14:00 UTC. It 
was a quarterly meeting, which means we invited representatives 
from companies using D in production. We normally would have 
scheduled it on the first Friday of the month, but delayed it a 
bit to allow everyone time to return and/or recover from the 
holiday period. The meeting lasted around 2.5 hours.

Unfortunately, I overlooked that audio output was disabled on OBS 
Studio when I recorded the meeting. I can hear myself, but no one 
else. All the good stuff was said by everyone else. I enlisted 
the help of some of the other attendees in recalling what we 
discussed. So what follows is a very light summary of a rather 
long meeting, cobbled together from the memories of a few 
different people several days after. I did not get input from 
everyone who attended the meeting, so I welcome any of them to 
fill in any additional gaps they may remember.

The following people attended (those with DLF next to their names 
are either D Language Foundation board members, paid employees, 
or affiliated volunteers):

* Walter Bright (DLF)
* Iain Buclaw (GDC/DLF)
* Ali Çehreli (DLF/Mercedes Benz R & D North America)
* John Colvin (Symmetry)
* Martin Kinkelin (DLF/LDC)
* Dennis Korpel (DLF)
* Mario Kröplin (Funkwerk)
* Max Haughton (DLF/Symmetry)
* Mathias Lang (DLF/Symmetry)
* Razvan Nitu (DLF)
* Mike Parker (DLF)
* Robert Schadek (DLF/Symmetry)
* Amaury Séchet (Symmetry)
* Robert Toth (Ucora)
* Bastiaan Veelo (SARC)




Robert said he was there to listen this time, but he did 
contribute throughout. Martin had not had any time since the last 
meeting to prepare the next LDC release. Iain, Max, Mathias, and 
Ali simply had nothing to report. I joked with Mathias that I was 
glad I was recording it (he usually has more than one thing to 
report, and often brings up something else at the end when I ask 
if anyone has anything else). Next time, I should knock on wood.


Robert gave an update on the Bugzilla-GitHub migration. He 
provided some details about its current state and hoped it would 
be ready to use by the end of the month. I asked if, when the 
time comes, I should just let it run on a VPN rather than my PC. 
He said that because of the GitHub API's rate limit, it shouldn't 
hurt to let it run on my PC. There were then some questions about 
details, e.g., should the script include only Bugzilla numbers in 
the migrated issues or link to the original, and I mentioned we 
should get in touch with Brad Roberts to set the Bugzilla into 
read-only mode. (This came up again in our February meeting three 
weeks later.)

Robert had already migrated the tools repository issues, so if 
anyone wants to see what that looks like they can now. [All of 
the issues from the author 
`dlang-bugzilla-migration`](https://github.com/dlang/tools/issues?q=is%3Aissue+is%3Aopen+author%3Adlang-bugzilla-migration+
ort%3Aupdated-desc) were migrated from Bugzilla.


Bastiaan had encountered an issue on his project at work related 
to the DMD installer on Windows. The installer has the option to 
add the compiler's path to the `PATH` environment variable, but 
checking it causes it to add the path to the 32-bit compiler even 
on 64-bit systems. This came to their attention when DMD suddenly 
started running out of memory when compiling their code base but 
was only using 4GB. [He filed an 
issue](https://issues.dlang.org/show_bug.cgi?id=23623) and 
[submitted a fix](https://github.com/dlang/installer/pull/555). 
Now, the installer with 2.102.0 will set properly the path to the 
64-bit compiler on 64-bit systems.

He also brought up a nearly year-old regression with dub related 
to `$PACKAGE_DIR` and the `sourceLibrary` package type. This was 
initially an annoyance for them but has become a blocker 
preventing them from upgrading the compiler since 2.100.0.S Jan 
Jurzita did some work on it last year, but it's still open as I 
write this summary. I've pinged Mathias and Jan to see if they 
can get it resolved.


In the summary of our December meeting, you can read [Robert 
Schadek's report](https://github.com/dlang/installer/pull/555) of 

project, as well as some of Robert's own frustrations. John came 
to us in this meeting to expand on that and asked Amaury along to 
provide his perspective.

This was a very long, very heavy discussion. Even if I did have 
the audio, there's no way I could reasonably cover in detail 
everything that we discussed. You can get the main thrust of the 
topic from [a forum post John wrote 
up](https://forum.dlang.org/post/xamclovgxzzrjzntengl forum.dlang.org) at the
beginning of last December in response to Walter's request for feedback on a
Sum Types proposal. Essentially, he's concerned that we keep moving on with new
features while there are fundamental problems in the compiler and language that
persist. People who are already sold on D and have used it for a long time have
learned to live with them, either by working around such issues or ignoring
them. That's not an ideal situation, but it's even worse when you're talking
about bringing non-D programmers up to speed on D. For them, those little
cracks in the foundation add up to a big, gaping hole that turns them off. This
is the situation Symmetry and other big D shops face when they have to hire
people who have never used D.

Essentially, John and Amaury were making an appeal that we put 
more value on a solid foundation. Things should "just work".

The conversation about this snaked back and forth, sometimes 
going off on short tangents, with almost everyone providing 
input. As I recall, Walter reiterated that he can't do anything 
with general descriptions of problems; he needs specific issues 
that he can sit down and fix. John and Amaury both provided some 
examples. I noted that part of the purpose of my campaign to 
collect gripes and wishes was to help us identify the kind of 
fundamental problems they described and get them all gathered in 
one place and prioritized, then we can figure out how to muster 
the resources to fix them. We were (and still are) in the midst 
of a period of organizational development, and I expected we'd be 
ready to start tackling this sort of thing in April or May. John 
said that was great, but he hoped we could make progress on some 
things before then.

That's all the detail I have right now on that discussion. 
Ultimately, Walter decided to put the Sum Types proposal aside 
for now and began directing his efforts toward fixing some 
fundamental issues in Bugzilla. At the end of an email discussion 
a few weeks later, he and Átila decided that stability and 
robustness should be our primary focus for the next year.

I'll again take this opportunity to encourage everyone to send me 
your gripes and wishes at social dlang.org. What do you consider 
to be fundamental issues with the language, tools, or ecosystem? 
Please be as specific as you can.


Mario said Funkwerk had no pressing issues. However, he wanted to 
know about any potential plans for multiple `alias this`. He 
noted that in the old Wiki-based DIP system, [a proposal for the 
feature](https://wiki.dlang.org/DIP66) had been conditionally 
approved. He recalled the DIP author had begun an implementation. 
The status of the DIP had never been updated, so was it still 
something we were intending to pursue?

Walter said no, we were not going to support multiple `alias 
this`. It has the same issues as multiple inheritance and opens 
the door to the problems that arise from that. This took us into 
a discussion about `alias this` in classes, and ultimately a 
decision that it should be removed from the language.

Mario ended by suggesting that someone should update the wiki 
page for DIP 66 to indicate that it's rejected.

Razvan [submitted a PR deprecating `alias this` in 
classes](https://github.com/dlang/dmd/pull/14812) the next day. 
Amaury [initiated a forum 
discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb
dp forum.dlang.org) a few days later. And I've now updated the status of DIP 66.


Dennis asked about the future direction of `-betterC`. A number 
of people had raised issues about `-betterC` disabling 
DRuntime-dependent features even for CTFE, and while there had 
been some small fixes, there had yet been no consensus on how to 
solve the problem in general.

He then listed three possible approaches:
* Explicitly annotate code as CTFE-only with new syntax: 
`pragma(ctfe)`, `if (ctfe)` etc. Walter noted that the syntax is 
an extra `()`.
* Implicitly make functions using DRuntime features as CTFE-only. 
This might be surprising and unintuitive
* Generate run-time errors instead of compile-time errors. This 
makes errors easier to slip by.

Martin suggested a fourth option: phase out `-betterC` because 
it's a "pile of hacks". Dennis considered that but thought 
BetterC users would not be happy when it gets deprecated without 
a suitable replacement. Walter said that the best approach 
couldn't be decided in the meeting, and should be discussed in an 
e-mail/forum post.

As a final question, Dennis asked what the "official" intended 
use for BetterC was in the first place: just a C migration tool 
or also something for new D code. I said `-betterC` shouldn't be 
used for writing new code. Walter said it can be used for 
whatever calls for it, be it integrating with C, targeting 
embedded systems, or any scenario where you don't want to link 
DRuntime.

Walter subsequently [submitted a 
PR](https://github.com/dlang/dmd/pull/14913) for the compiler to 
recognize `if(__ctfe)` blocks and [a companion 
PR](https://github.com/dlang/dmd/pull/14830) to disable the 
generation of `TypeInfo` in `if(__ctfe)` blocks.


Razvan asked what everyone thought about [a specific Bugzilla 
issue](https://issues.dlang.org/show_bug.cgi?id=3720). Given an 
aggregate type `F`, the compiler allowed taking the address of a 
member function `F.foo` without an instance of `F`, returning a 
function pointer rather than a delegate.

Razvan had submitted a PR in December. His fix was to simply type 
what is returned as being `void*`. This would keep the current 
behavior, but it would be ` system` require a cast to the desired 
type in order to use it. However, there were folks that didn't 
want to lose the type information and proposed instead to have 
some extra typing on the result, such as `void delegate(S*)`.

It seems the end result was a recommendation for the latter, as 
that's what Razvan amended the PR to implement. However, that 
apparently led to a new issue, and [the PR is yet to be 
resolved](https://github.com/dlang/dmd/pull/14688).

Razvan also let us know that the GSoC application period was 
opening on January 23rd, and asked us to contact him if we had 
any project ideas or were willing to be a mentor.


Walter is always the last to take a turn in our meetings. On this 
occasion, he felt like the meeting had gone on long enough. 
During the discussion about fundamental problems, he mentioned 
his frustrations with how `build.d` is invoked by the compiler 
under test when running the test suite. He had nothing else to 
report. (This issue with `build.d` was the topic he brought up 
during his turn at our February meeting).


Our next meeting took place on February 3rd at 15:00 UTC. It was 
a monthly meeting.

If your company is using D in production and you'd like to send a 
representative to our quarterly meetings, please let me know! 
We'll do what we can to help solve any issues you may have with 
D, but we're also interested in hearing your perspective on the 
topics we discuss. Our next quarterly meeting should take place 
on April 7th.
Feb 27 2023
next sibling parent reply newbie <d007 gmail.com> writes:
On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:

 The January meeting took place on January 13th at 14:00 UTC. It 
 was a quarterly meeting, which means we invited representatives 
 from companies using D in production. We normally would have 
 scheduled it on the first Friday of the month, but delayed it a 
 bit to allow everyone time to return and/or recover from the 
 holiday period. The meeting lasted around 2.5 hours.

 [...]



betterC is much more important for some user, please don't phase 
out `-betterC`.

with `betterC` you can target into new platform without much 
work, and easy to deal with dynamic library,  generate much fast 
and smaller binary.
Feb 27 2023
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote:

 with `betterC` you can target into new platform without much 
 work, and easy to deal with dynamic library,  generate much 
 fast and smaller binary.


you can do this without betterC too. often easier. And it could 
be even easier with a little bit of work that benefits everybody.
Feb 27 2023
parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Monday, 27 February 2023 at 14:24:38 UTC, Adam D Ruppe wrote:

 On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote:

 with `betterC` you can target into new platform without much 
 work, and easy to deal with dynamic library,  generate much 
 fast and smaller binary.


 you can do this without betterC too. often easier. And it could 
 be even easier with a little bit of work that benefits 
 everybody.


The custom runtime route is a mistake to expect from users, why 
should i manage all of this, it should just work, well you are 
forced because of X, Y, Z are not yet ported! so you cherry pick 
on a code basis, rather than on a feature basis

You'll also have to keep track of the compiler developments in 
case runtime hooks get changed, also if you are not careful about 
your implementation you have silent bugs (i had one with switch 
errors that was hard to track down, i had to copy/paste code from 
your repo)

With C/C++ and even Rust/Zig/Go(tinygo), you don't have that kind 
of problems

The bare is set by other languages already, -betterC is helping 
staying on buisness for that kind of purpose
Feb 27 2023
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote:

 betterC is much more important for some user, please don't 
 phase out `-betterC`.


BetterC isn’t going anywhere. Too many people use it.
Feb 27 2023
parent Ferhat =?UTF-8?B?S3VydHVsbXXFnw==?= <aferust gmail.com> writes:
On Monday, 27 February 2023 at 23:00:41 UTC, Mike Parker wrote:

 On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote:

 betterC is much more important for some user, please don't 
 phase out `-betterC`.


 BetterC isn’t going anywhere. Too many people use it.


Using word "Too" is scary enough for me here :D
Feb 28 2023
prev sibling next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
I just want to make this point about -betterC.

As a switch it should just be switching other things off. As a result 
its just a marketing name of D without the language extensions that 
depend on druntime.

It isn't that way in practice, but it should be.

However I think there is a pathway forward here.

My number 2 priority for me this year is to see compiler hooks resolved. 
They should ALL look like this (more or less):

```d
void hook(T)(T thing) {
	version(Feature) {

	} else
		static assert(0, "feature not had, can't do Y");
}
```

Lowering should be the last step but only for functions that need to be 
codegen'd.

This allows significant simplification in the compiler, and allows for 
features to work at CT that won't go into the binary.

There is a lot to this strategy that I am not saying here as it isn't 
relevant to -betterC. There is some very real possibility here to making 
our lives better I think.
Feb 27 2023
prev sibling next sibling parent reply M.M. <matus email.cz> writes:
On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:

 ...

 Dennis asked about the future direction of `-betterC`...

 ... He then listed three possible approaches:
 * Explicitly annotate code as CTFE-only with new syntax: 
 `pragma(ctfe)`, `if (ctfe)` etc. Walter noted that the syntax 
 is an extra `()`.
 * Implicitly make functions using DRuntime features as 
 CTFE-only. This might be surprising and unintuitive
 * Generate run-time errors instead of compile-time errors. This 
 makes errors easier to slip by.

 Martin suggested a fourth option: phase out `-betterC` because 
 it's a "pile of hacks"...

 As a final question, Dennis asked what the "official" intended 
 use for BetterC was in the first place: just a C migration tool 
 or also something for new D code. I said `-betterC` shouldn't 
 be used for writing new code. Walter said it can be used for 
 whatever calls for it, be it integrating with C, targeting 
 embedded systems, or any scenario where you don't want to link 
 DRuntime.
 ...


In the recent post by Mike Parker, betterC is used as a great 
alternative to C for writing bare-metal RISC-V application:

https://forum.dlang.org/post/eemwycjmfqvedgggnvnr forum.dlang.org
Feb 27 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 27 February 2023 at 14:18:04 UTC, M.M. wrote:

 In the recent post by Mike Parker, betterC is used as a great 
 alternative to C for writing bare-metal RISC-V application:


Real D can do this too.

betterC needs to die, it is just arbitrary special cases that add 
tech debt to the compiler and distract from D's real capabilities.
Feb 27 2023
parent M.M. <matus email.cz> writes:
On Monday, 27 February 2023 at 14:25:29 UTC, Adam D Ruppe wrote:

 On Monday, 27 February 2023 at 14:18:04 UTC, M.M. wrote:

 In the recent post by Mike Parker, betterC is used as a great 
 alternative to C for writing bare-metal RISC-V application:


 Real D can do this too.


Oh, that's a bit new information to me. But yes, I do not use 
betterC and I am not dlang-savvy, so happy to hear standard dlang 
can do as well.
Feb 27 2023
prev sibling next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
I use -betterC because i can focus on the language and build upon 
it, i don't have to deal with the slowness of phobos and more 
importantly, i don't have to wait for phobos or druntime to be 
ported to WASM in order to be able to target to WASM, i target 
WASM today

It also makes me confident that none of my game code will 
accidentally call the GC, as i banned the use of the GC for this 
particular project (game)

I can focus on what i love about C with the greatness of D (the 
language)

My project fully recompile (clean build, game+engine) in just 
1.2s, thanks Walter!

The only complain i have about betterC, and D in general are the 
error messages, sometimes just having new lines with proper 
spacing makes errors easier to read, i made a comment in one 
PR(related to improving betterC error message) that it was 
helpful and very much welcome, so looks like things are going to 
improve


 Walter decided to put the Sum Types proposal aside for now


That's super sad to hear.. i was eagerly hoping tagged union 
would come sooner rather than later.. it's one feature that 
enables writing useful with less noise

I want to replace that kind of ugly code that i have, notice how 
easy it is to have bugs if you are not careful what field you 
use, not safe!: (no, template is not the solution)

```D
enum EventType: ubyte
{
     QUIT,

     GFX_RESIZE,

     INPUT_KEY_DOWN,
     INPUT_KEY_UP,
     INPUT_KEY_TYPED,
     INPUT_TOUCH_DOWN,
     INPUT_TOUCH_UP,
     INPUT_TOUCH_DRAGGED,
     INPUT_MOUSE_MOVED,
     INPUT_SCROLLED,
}

struct Event
{
     long time;
     bool consumed;

     EventType type;
     union
     {
         // GFX
         Resize resize;

         // INPUT
         KeyDown key_down;
         KeyUp key_up;
         KeyTyped key_typed;
         TouchDown touch_down;
         TouchUp touch_up;
         TouchDragged touch_dragged;
         TouchMoved touch_moved;
         Scrolled scrolled;
     }
}


(..)


         // update key state
         foreach(Event* e; engine.queue)
         {
             if (e.consumed) continue;

             switch (e.type) with (EventType)
             {
                 case INPUT_KEY_DOWN:
                     switch(e.key_down.key)
                     {
                         (..)
                     }
                 break;
                 case INPUT_KEY_UP:
                 switch(e.key_up.key)
                 {
                         (..)
                 }
                 break;

                 case INPUT_TOUCH_DOWN:
                     if (e.touch_down.button == 1)
                         (..)
                 break;
                 case INPUT_TOUCH_UP:
                     if (e.touch_up.button == 1)
                         (..)
                 break;

                 default:break;
             }
         }


```

I think expecting users to ask for new features shouldn't be seen 
as something bad

It's great to have people discuss language improvement, it gives 
the ability to talk about and remind people about existing 
features, and potentially their issues


And what a better opportunity than to remind ones who think bugs 
in weird and cryptic corner cases, is what turn off people

What turn me off from D is that kind of issues: 
https://github.com/dlang/dub/issues/2600

When you start to import things from the std and it makes your 
compile time go from 5seconds (already an eternity) to 10 
seconds, and people think "it's not a problem"

tagged union would help reduce the code complexity, template 
usage and bugs by a significant amount of time, as well as 
improving error messages 
https://forum.dlang.org/thread/zsxipgibubqgnwwwxhqx forum.dlang.org
Feb 27 2023
prev sibling parent reply bachmeier <no spam.net> writes:
On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:


 Razvan [submitted a PR deprecating `alias this` in 
 classes](https://github.com/dlang/dmd/pull/14812) the next day. 
 Amaury [initiated a forum 
 discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb
dp forum.dlang.org) a few days later.


Is there a replacement? If not, why is this even being discussed? 
I'm all for breaking changes if there's a benefit and an easy 
path to maintain the existing functionality. This fails on both 
counts. If you want to enforce that it's not used, add a flag, 
but don't take it away just for the sake of taking it away.


 Martin suggested a fourth option: phase out `-betterC` because 
 it's a "pile of hacks". Dennis considered that but thought 
 BetterC users would not be happy when it gets deprecated 
 without a suitable replacement.


If you don't like BetterC, don't use BetterC. It *already* 
requires a flag.

More generally, deprecation decisions like this shouldn't be made 
by a small group of people that write a tiny percentage of the D 
code running in the real world. That same process gave us a safe 
by default proposal that would have made it impossible to 
interoperate with C code.
Feb 27 2023
next sibling parent reply Dom Disc <dominikus scherkl.de> writes:
On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote:

 On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:


 Razvan [submitted a PR deprecating `alias this` in 
 classes](https://github.com/dlang/dmd/pull/14812) the next 
 day. Amaury [initiated a forum 
 discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb
dp forum.dlang.org) a few days later.


 Is there a replacement?


Yes. And there always was: In classes this was only an additional 
way to do, what should better be done with inheritance.
Feb 27 2023
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 27 February 2023 at 15:39:35 UTC, Dom Disc wrote:

 On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote:

 On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:


 Razvan [submitted a PR deprecating `alias this` in 
 classes](https://github.com/dlang/dmd/pull/14812) the next 
 day. Amaury [initiated a forum 
 discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb
dp forum.dlang.org) a few days later.


 Is there a replacement?


 Yes. And there always was: In classes this was only an 
 additional way to do, what should better be done with 
 inheritance.


Generally speaking, I agree, but it does add a little bit of 
mental overhead for a user if they want to change from struct to 
class. Hopefully the error message of a class alias this points 
users in the direction of inheriting instead.
Feb 27 2023
prev sibling parent bachmeier <no spam.net> writes:
On Monday, 27 February 2023 at 15:39:35 UTC, Dom Disc wrote:

 On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote:

 On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:


 Razvan [submitted a PR deprecating `alias this` in 
 classes](https://github.com/dlang/dmd/pull/14812) the next 
 day. Amaury [initiated a forum 
 discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb
dp forum.dlang.org) a few days later.


 Is there a replacement?


 Yes. And there always was: In classes this was only an 
 additional way to do, what should better be done with 
 inheritance.


That is not my understanding from the linked thread. For 
instance, someone said it can be used as a substitute for 
multiple inheritance. It seems that anyone using it that way 
would be losing working code for no reason due to this 
deprecation.
Feb 27 2023
prev sibling parent reply Guillaume Piolat <first.last spam.org> writes:
On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote:

 Is there a replacement? If not, why is this even being 
 discussed? I'm all for breaking changes if there's a benefit 
 and an easy path to maintain the existing functionality. This 
 fails on both counts. If you want to enforce that it's not 
 used, add a flag, but don't take it away just for the sake of 
 taking it away.


What would be really cool and end-game would be if the gap 
between druntime and custom runtime such as HipremeEngine would 
be smoothed out and only one druntime needs to exist. I think 
this has been the direction for years: ProtoObject, 
Object.factory, etc.
Mar 01 2023
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 March 2023 at 13:01:03 UTC, Guillaume Piolat 
wrote:

 I think this has been the direction for years: ProtoObject, 
 Object.factory, etc.


These things don't really help with it unfortunately, but yes, 
this is the best goal.
Mar 01 2023
prev sibling parent Hipreme <msnmancini hotmail.com> writes:
On Wednesday, 1 March 2023 at 13:01:03 UTC, Guillaume Piolat 
wrote:

 On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote:

 Is there a replacement? If not, why is this even being 
 discussed? I'm all for breaking changes if there's a benefit 
 and an easy path to maintain the existing functionality. This 
 fails on both counts. If you want to enforce that it's not 
 used, add a flag, but don't take it away just for the sake of 
 taking it away.


 What would be really cool and end-game would be if the gap 
 between druntime and custom runtime such as HipremeEngine would 
 be smoothed out and only one druntime needs to exist. I think 
 this has been the direction for years: ProtoObject, 
 Object.factory, etc.


In the experience I got from dealing with the D runtime, this is 
what I feel like it needs:

Compiler could support a flag which is basically saying: User 
must provide hook functions such as malloc/free, exit(or assert) 
(those are the most  basic ones), for the runtime to work.

So, instead of being dropped on a static assertion with plenty of 
types not found, you get into a runtime error from the features 
actually being used. That way, no one will ever need to create a 
custom runtime that does nothing only for the sake of it being 
compiled.


This is all possible to implement too by using weak compiler 
attribute. The custom runtime I done is roughly 99% of what the 
current runtime is, the only difference being those allocators 
and not supporting throw because I don't know how to implement 
stack rewinding.

While that is not done I'll keep maintaining my own for accessing 
those unimplemented systems.
Mar 01 2023