D Language Foundation January 2023 Quarterly Meeting Summary

[Mike Parker]

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)

## The summary

### Mathias, Martin, Robert T., Iain, Max, and Ali
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 S.
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+sort%3Aupdated-desc) were migrated from Bugzilla.

### Bastiaan
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.

### John and Amaury
In the summary of our December meeting, you can read [Robert 
Schadek's report](https://github.com/dlang/installer/pull/555) of 
a Symmetry programmer who moved from D to C# for an internal 
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 at dlang.org. What do you consider 
to be fundamental issues with the language, tools, or ecosystem? 
Please be as specific as you can.

### Mario
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/roaaoujwgkzednetbndp@forum.dlang.org) a few days later. And I've now updated the status of DIP 66.

### Dennis
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
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
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).

### The next 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.