None of that would be an issue if we had a c++ dump backend.

After that its just a matter of distribution for druntime/phobos, rather than a hard problem that has to be solved on a case by case basis.

But alas, that wasn't how D was built or structured.

On Tuesday, 19 December 2023 at 18:37:47 UTC, H. S. Teoh wrote:
> I'm a heavy Phobos user, and std.algorithm / std.range are among the best parts of Phobos.  Among the better modules are std.datetime, std.path, std.bigint, std.regex (I'm a regex addict). std.process is awesomely convenient for dealing with processes; one of the better-designed APIs in Phobos IMO.  std.math / std.numeric are pretty standard, with a few nice things in there, though there's that strangeness with real vs. double. std.stdio is also pretty standard, but could be improved (replace with I/O pipes?). I'm addicted to std.format for its convenience but the implementation really could use some improvement, same goes for std.conv. std.uni's implementation could also use some improvement, but what's there is pretty serviceable for dealing with Unicode (main missing features: Unicode line-breaking algorithm and grapheme width -- I have an incomplete implementation of the latter but never got around to finishing it).
>
> std.meta / std.traits / std.typecons are good for metaprogramming, though there are some weird bits.
>
> Other parts of Phobos are meh, like std.container (I use it from time to
> time but the API is klunky and rough around the edges), std.digest
> (never used it, kinda random why it's in Phobos), std.encoding (hardly
> ever use it), std.experimental (when it is coming out of deep freeze?),
> std.json (meh), std.xml (bleh).  std.getopt gets the job done, but has
> weird differences with standard Posix getopt() for no good reason, which
> made me write my own getopt on at least 3 separate occasions.
> std.signals - never used it, std.socket (meh), std.bitmanip (sometimes
> useful), std.base64 (kinda random, used it once or twice but that's
> about it -- honestly could just go in a dub library), std.csv (meh - my
> fastcsv alternative runs way faster, though with no validation).
> std.net.curl - weird API, std.net.isemail - seems like a totally random
> thing to put in Phobos.  A lot of this stuff honestly could do better as
> dub packages / external repos.

A great list and analysis!

-Steve

On 12/19/2023 5:26 PM, Richard (Rikki) Andrew Cattermole wrote:
> None of that would be an issue if we had a c++ dump backend.

I don't know what that is.

All it means is to convert D to C++ mechanically.

We have a partial implementation for C++ headers already.

That isn't going to work long term.

We already have at least one more release in between that one and current versions.

Using the C++ dump approach is significantly better, you go immediately to the latest version. With the old bootstrap approach you have to maintain N frontends with their glue code indefinitely. It doesn't scale.

On 20/12/2023 3:49 PM, Siarhei Siamashka wrote:
> However it's good enough to develop software.

But not good enough to compile current releases of the frontend.

We currently have a chain of compilers if you want to bootstrap latest compiler from C++.

That chain can only get longer.