D Language Foundation Quarterly Meeting, October 2021

[Mike Parker]

This meeting took place on October 22nd at 13:00 UTC. Apologies 
for the delayed summary.

This was a quarterly meeting, meaning there were two parts. The 
first was focused on industry reps and contributors using D in 
production; the second was the monthly D Language Foundation 
meeting. If you are using D in production and would like to 
participate in our quarterly meetings, please let me know.

The meeting lasted three hours. The following people attended:

**Industry Reps**
Iain Buclaw for GDC
Martin Kinkelin for LDC
Mario Kröplin for Funkwerk
Mathias Lang for BPF Korea
Robert Schadek for Symmetry Investments
Joseph Wakeling for Frequenz

**Contributors**
Petar Kirov
Vladimir Panteleev
Steven Schveighoffer

**D Language Foundation**
Andrei Alexandrescu
Walter Bright
Ali Çehreli
Max Haughton
Átila Neves
Razvan Nitu

### Frequenz
Joseph had no issues to report, but he brought up his concerns 
about the state of D in relation to Rust. This led to a 
discussion that touched on the excitement of things happening in 
the Rust space (new projects, particularly in the field of Data 
Science), the availability of libraries in the Rust ecosystem (in 
many cases, it's easier to get a new project going in Rust than 
in D), and marketing (he knows programmers who are highly 
enthused by Rust's offerings and unenthusiastic about the 
potential of D by comparison).

This led to a recurring discussion throughout the meeting about 
marketing, branding, and the availability of libraries. Some 
salient points were raised throughout:

* Word of mouth is a powerful form of marketing, and languages 
with solid tooling support (IDEs that almost write the code for 
you) and a large library ecosystem (like Go's "lego style" 
programming, where much of what you need for modern programming 
has already been written) have a lot more to talk about. We have 
a great language to talk about, but we're missing the other stuff.
* We may be appealing to the kind of programmer who is happy with 
Emacs and has no problem writing the support libraries they need, 
but that sort of programmer is not the future of programming.
* We don't need to be a better C, because no one wants to write 
new code in C. We need to just be *better*.
* HN/Reddit/Etc have a constant stream of "I wrote X in Rust" 
articles. We need more people who are using D to write about/talk 
about what they are doing so that others can see it.
* The biggest languages have a story. (Java: write once run 
anywhere, the language of the internet; Rust: memory safety 
without a GC; Go: goroutines). What is D's story? It's not one 
big thing, but a lot of little things, and that's not a strong 
story.
* Branding. We need to determine what we are as a brand and 
should consider hiring a branding expert.

### Funkwerk
Mario said Funkwerk wants to create containers that can accept 
arbitrary types, and that includes accepting `immutable` and 
`const` types without the containers, in turn, becoming 
`immutable`/`const`. Unfortunately, they could not use the Phobos 
`Rebindable` for this, as it doesn't wrap structs. Mathis Beer 
worked on a solution, and Mario asked him to [submit it to the 
forums for 
feeback](https://forum.dlang.org/post/qnzxruolyeozohflretb@forum.dlang.org). It received very little. And they aren't happy with it as it's a "very tricky, very ugly" solution that relies on compiler behavior. Should they continue to use it and risk it breaking if the compiler is changed? Átila said he would look at their code.

A second issue was regarding a Funkwerk PR to dfmt that adds a 
`single_indent` option to dfmt for continuation lines since dfmt 
only supported double indent continuations, something that was 
rejected for the D Style Guide. The PR got held up waiting for 
feedback from Brian Schott, and a later request to merge it 
anyway received no response. Most of the people present at the 
meeting have merge rights to dfmt and agreed it should be merged, 
[and Razvan did 
so](https://github.com/dlang-community/dfmt/pull/535).

### Symmetry Investments
Robert said he has no major issues with his current project. He 
did circle back to the libraries/marketing discussion, and I 
summarized his remarks above. Other than that, he is happy using 
D every day.

He also said he has [continued working on 
"dud"](https://forum.dlang.org/post/cnkbatgkqtdmbldlnewl@forum.dlang.org) as his Fridays project at Symmetry. He is currently working on dependency resolution, based on the work done in dub. He intends to do a talk about dud and its dependency resolution at the next real-world DConf. He mentioned that in adding parsing support for JSON/SDLang dub recipes, he found several SDLang recipes that have unexpected syntax. Finally, though he expects to keep a legacy dub-like system, where the user types `dud` and the project builds and runs, he would like to connect to Átila's reggae for anything more complex.

### BPFKorea
Mathias reports that his company was hit by Issue #21929 two or 
three months ago, in code written by someone experienced with D. 
They would love a solution for it.

A few months ago, they were also hit by a bug in 
`-preview=dtorfields` that [was triggered in 
vibe.d](https://github.com/vibe-d/vibe-core/issues/283) and 
[reported in Issue 
#21989](https://issues.dlang.org/show_bug.cgi?id=21989) after 
Sönke Ludwig tracked it down. A PR for this issue by 
MoonlightSentinel is currently stalled, but the preview switch 
[was enabled by default in 
2.098.0](https://dlang.org/changelog/2.098.0.html#dtorfileds). 
BPFKorea was forced to disable the feature with 
`-revert=dtorfields`.

They also have some exception-related bugs on Alpine Linux, but 
the stack traces on Alpine don't work yet. He has done some work 
on getting them working but has not had time to finish it. He is 
hoping to fix that when he is able.

### LDC
Martin reported that LDC's DLL support is working well and has 
been used successfully at Symmetry.

### Iain
Over the last quarter, Iain has submitted patches to GCC for 
bootstrapping the D compiler and is waiting on approval. Once he 
has that, he'll be able to delete the current C++ front end and 
libraries and add in the master versions of dmd (the d front 
end), druntime, and phobos. With that, GDC will be at the latest 
version of D.

Iain has been working with Walter on Import C. A recent PR from 
Walter adding support for `va_start` and `va_end` now enables 
them to cleanly compile a preprocessed zlib to object code. Iain 
will soon be testing the output against zlib's test suite to see 
if there are any hidden run-time bugs in ImportC. They've 
selected zlib as a test target because it is compiled in Phobos 
with DMC, so it would be great to get it compiling with DMD 
instead.

He also brought up our aging server infrastructure, including 
digitalmars.com, dlang.org, the auto tester, and more, which has 
been a topic of discussion in past meetings. This led to a 
discussion about the auto tester (e.g., what is it covering that 
our other CI solutions are not, how switching to a monorepo would 
benefit the auto tester, how can we avoid unnecessary builds, 
etc.), our CI services, and the state of the current auto tester 
server stack.

(A couple of related notes.

I participated in a non-foundation meeting yesterday with 
Vladimir, Petar, Mathias, Max, and Razvan as a preliminary 
discussion of what it would take to merge some of the core 
repositories into a single repo. This resulted in a plan to put 
together a proposal and bring it to a monthly Foundation meeting, 
tentatively targeting our November meeting.

I am attending a foundation meeting later today with someone who 
has volunteered to advise us on bringing our server 
infrastructure under Foundation management and multiple admins. 
This meeting is intended to provide our adviser with a clear 
picture of the existing servers and our goals so that he can 
formulate some suggestions and bring them to one of our future 
monthly meetings.)

### Vladimir
[Vladimir's open-source btdu 
project](https://github.com/CyberShadow/btdu) has been picking up 
recently among users of [the btrfs file 
system](https://btrfs.wiki.kernel.org/index.php/Main_Page). A 
problem he's encountered is one of packaging and distribution. 
For example, on Debian: DMD isn't packaged in the official 
distro, GDC has an old front end, and the LDC packages are 
outdated. This has led to a poor experience for new users of his 
software, who often decide to use something else. This led to a 
discussion about how to get D compiler packages into more 
distros. Most distros do not allow people to just start 
submitting packages without first establishing trust in some 
form. The best approach will likely be to sponsor someone who 
already has access.

He also discussed some plans he has for some changes to DustMite 
that he hopes will introduce D to more people. I will say no more 
about that for now and leave it to Vladimir to make the 
announcement when he is ready.

### Petar
Petar is the CTO of a small startup using D in a limited 
capacity. He brought up two minor issues they have encountered. 
The first: `-chackaction=context` causes linker errors in release 
builds. For now, they are fine using the switch only in unit test 
builds. The second: they could not find an easy way to customize 
the visualization of `DateTime` in vibe.d, but they were able to 
work around it. He feels that though the project is small it was 
a success story for its use case.

Petar is the only active maintainer of [DLang 
Tour](https://tour.dlang.org/) but is not happy with its current 
state. He has ideas on how to improve it but has not been able to 
make the time for it. He would be happy to guide anyone who would 
like to volunteer to do some work on it and will resume work on 
it himself when he has more time. If anyone is interested please 
let us know in this thread. I will make a more visible effort to 
recruit someone later. One of the things he would like to do is 
use DLang Tour to make all of the examples in Ali's book runnable.

Finally, Petar believes the tools that Hackerpilot (Brian Schott) 
developed (dcd, dfmt, dsymbol, etc.) are extremely useful, but it 
can be annoying to contribute to them while they are in separate 
repositories. Sometimes, I change in one requires a change in 
another. He would like to see them all merged into a single 
repository.

### Steven
Steve is teaching programming to some kids. He was originally 
using JavaScript, then Lua and Roblox, and now D and raylib-d (of 
which he has since become the maintainer). This has shown him 
that most of our existing D resources are targeted at people who 
already know how to program. We have very few resources geared 
toward teaching D to people who do not know how to program. 
Related to that, it's difficult to teach the kids how to 
interpret error messages. This would be much easier if compiler 
error messages and Phobos/DRuntime error messages were improved. 
For example, a `RangeError` on an invalid array index should 
report what the number was that caused the problem; failed 
asserts should report the offending expression; etc. This would 
be useful to everyone, not just beginners.

### The fate of `-preview=in`
`-preview=in` came up briefly at a previous meeting, in the 
context of a larger discussion, as a mistake that should be 
killed. Given that it was implemented by Mathias Lang, we decided 
to bring him into a future meeting to present his case for 
keeping the feature around and ultimately moving it out of 
preview.

Mathias provided a bit of background on the feature. `in` used to 
mean `scope const`, but then DIP 1000 came along, and `in` was 
changed to just `const`. Then later, a preview switch was 
introduced to make `in` mean `scope const` again. Mathias felt 
that `in` by itself was not very useful, so he saw an opportunity 
to improve it based on a use case in BPFKorea's codebase. So he 
changed its behavior, behind `-preview=in`, such that `in` means 
`const scope ref`, with the addition that the compiler is free to 
optimize to pass by value when it can (e.g., small POD structs) 
and it accepts rvalue references. The big objection raised in 
past discussions was aliasing. Mathias feels that is a more 
general problem, is a rare problem, and `@live` is supposed to 
help with that. BPFKorea has been using the feature in production 
for over a year, and in that time it has only caused a single 
bug, which came down to the fact that they weren't using 
`preview=dip1000`, so `scope` wasn't being enforced. Their code 
is sensitive about how things get copied around, and they have 
had memory corruption in the past. `-preview=in` solved that 
problem. He then mentioned some ideas he had to make it more 
useful, which led to some discussion that isn't relevant to this 
summary.

This was a long discussion that took up a full hour.

Martin, Petar, and Ali voiced strong support for the feature. 
Some of their arguments in favor:

* it avoids the situation in templated code with an `in ref` 
parameter where you have, e.g., an `int` being passed by 
reference; the compiler can optimize this to pass the `int` by 
value.
* you don't have to concern yourself with deciding whether to 
pass a `const` parameter by reference or by value; the compiler 
will do for you the best thing on the current platform.
* this eliminates the need for multiple function overloads and/or 
`static if` blocks to do manually what this does for you, which 
simplifies the language (and is something easier to understand).
* it eliminates the need for `-preview=rvaluerefparams` (and [the 
DIP on which that feature is 
based](https://github.com/dlang/DIPs/pull/218)) and does not 
allow rvalues to be mutated.


Átila and Walter had strong reservations. Their two major 
objections:

* (Átila) if `-preview=rvaluerefparams` is broken, or the DIP is 
wrong, we should fix it.
* (Walter) the issue with `-preview=in` and aliasing isn't that 
it can happen, it's that it can sometimes happen and sometimes 
not depending on if the compiler optimizes to pass by value, and 
that can vary from platform to platform; this is a major 
inconsistency in that the behavior is unpredictable; that 
aliasing is rare makes this a more pernicious problem that can 
silently introduce memory corruption.

When reading the above, you will probably think of things to say 
for or against specific arguments. I'm willing to bet that it was 
already said in this meeting. They drilled down deep into the 
weeds and raised several points and counterpoints related to the 
above arguments and other, more minor arguments. In the end, they 
found their way to an agreement on how to proceed.

`-preview=in` will not be killed. It needs to be changed such 
that:

* `in` always means `const scope ref`; the compiler will not 
attempt to pass by value based on platform-specific heuristics.
* `in` will accept rvalue references.
* the compiler can in the future optimize to pass by value to 
`in` with more appropriate heuristics (e.g., it can prove there 
is no aliasing).

### The next meeting
Phew! That was a longer summary than I expected to write. Our 
next meeting is a normal monthly meeting (no industry reps) and 
will take place on Friday, November 26th, at 14:00 UTC (the 
American clocks will be moved back an hour before then, so we 
have to move from 13:00 to 14:00 UTC so that we can keep it at 
06:00 PST for Walter and Ali).

It looks like the primary agenda item for the next meeting will 
be a discussion on merging the druntime repository into the dmd 
repository. If you have anything you'd like us to discuss, or 
would like to discuss with us, please let me know and I'll tell 
you if I can squeeze you in.