What’s the status of the OpenD fork?[0] I see Adam is still active there but I’m not sure if it’s had any impact beyond losing him as an upstream contributor.
There's a lot of smaller things that haven't been pulled though, like i merged a bug fix to module naming, which was an upstream PR from like 2018, a fix on library file name generation, a regression from 2019 but has a trivial workaround, a fix to redefined reflection names which everyone finds annoying, the implementation was written in 2017, but they had endless debates about syntax and i just made an executive decision and moved on but they still bikeshed... stuff like that, they're all little things but minor annoyances every time you hit them and the fixes were easy, so just do it!
Then the two bigger things I did they have talked about but probably won't do is i made the class monitor opt-in, this is a relatively big breaking change, I had to do fixes on 8 different projects. Each one took a few minutes, so not a huge deal, but still. They talked about this in an upstream meeting but decided against taking it (for now at least).
And then I changed the default init of all built in types to zero, including char and float, and this is controversial since float init to nan has legitimate advantages, and the breakage can be subtle if you don't catch it. I was on the fence personally, it more like a 51-49 vote rather than an obvious bug fix, but it is easier to explain to newbies that int and float both init to 0. In theory, you are supposed to explicitly initialize all these all the time, but in practice we know it is different.
So I think the competitive edge is pushing them a little. And I'm not anti-collaboration; I write blogs about my implementations with the hope that they'll give a little code review and that's been semi-successful, like the upstream backporters have indeed fixed bugs in my implementations so I'm happy to share back and forth, we both win that way.
FYI that had very little to do with OpenD merging the tuple syntax - at least from my perspective - Timon may feel differently. I was the one who got the ball rolling on the DIP for it and kept pushing the process forward, and I also helped Timon and Nick get it over the finish line by fixing an ICE in the backend caused by destructuring a tuple of structs.
I've wanted first class tuple syntax in D since 2013, and when Timon mentioned not having time to do a DIP for it, I offered to help. It would've happened regardless of whether it got merged into OpenD or not.
but maybe this is the first step toward something more useful.
My experience was the ldc impl was MUCH easier.... and optimizes much better, no surprise, but also compiled WAY slower. On dmd, the null checks barely affected compile speeds at all, but on ldc, the runtime impact isn't bad... but the compile time hit is ENORMOUS. I didn't even notice it at first, because I mostly use ldc just for cross compiles (another thing opend makes easy, `opend install xpack-win64` for example makes Windows builds just work, and it can do icons built in without third party toolchain as well, something hipreme took to upstream via his redub program that copied my implementation. he then added similar for Mac but I havent' pulled that back to opend yet, i will though) and I misdiagnosed.
Went looking for why the compile times were so much worse in opend ldc vs upstream (and btw note my definition of "so much worse" is like 3 seconds instead of 2 seconds, 50% is signifcant) and tried PGO and diffs in codegen and llvm versions...... then realized no, it is the null checks.
So the ldc implementation was easy and seems bug free (the bugs rikki fixed were in obscure corners of dmd's backend), and it optimizes well for runtime..... but wow it takes its sweet time to do that optimization. I'd appreciate someone else taking a look at that some day since there might be some better way to do it than I did (i basically copied the RangeError implementation on pointers for null check).
But I expect some day it'll come and then hopefully we'll make both of our compilers better.