D Language Foundation Monthly Meeting for February 2022

[Mike Parker]

## Monthly Meeting
The D Language Foundation's monthly meeting for February 2022 
took place on February 4 and lasted around 1.5 hours. The 
following foundation members, contractors, and contributors 
attended:

Walter Bright
Iain Buclaw
Ali Çehreli
Max Haughton
Martin Kinkelin
Mathias Lang
Átila Neves
Razvan Nitu
Vladimir Panteleev
Mike Parker

### Me
I opened the meeting with a question for Walter. After [a recent 
forum 
discussion](https://forum.dlang.org/post/aarigbnntabwbcuqsuzg@forum.dlang.org), someone had [submitted a DIP](https://github.com/dlang/DIPs/pull/222) that would change the runtime behavior of the default `toString` implementation in the `Exception` class such that it generates stack trace output only when an environment variable is set. Should this be a DIP or an enhancement request in Bugzilla? We had a brief discussion.

Vladimir pointed out that stack trace output is only useful when 
debug symbols are enabled.

Ali suggested that perhaps it could be configurable for 
`Exception`, but `Error` should always print. Átila and Mathias 
noted that anyone who wants this can just catch all `Exception`s 
in `main`. This doesn't handle static constructors, but they both 
said that static constructors that aren't `nothrow` are probably 
wrong anyway.

Walter said a DIP isn't needed---it's fine to post it in Bugzilla 
as an enhancement request.

Later, at the end of the meeting, Martin said he had looked into 
the DRuntime source. The stack trace handler is configurable by 
the user, so there may be no need for an enhancement request. It 
should be sufficient for the user to set the trace handler to a 
function that returns null.

### Martin
Martin said he was eager to see news about the 2.099 release. He 
felt it was the right time for the stable branch to be updated as 
some important breaking changes had recently made it into the 
compiler. This brought about a discussion about the number of the 
next version after 2.099: should it be 2.0100 or 2.100? The 
latter would match what we did with the pre-1.0 releases, which 
[went up to 
0.178](https://digitalmars.com/d/1.0/changelog2.html). We moved 
on quickly from this discussion without any definitive statement, 
but my impression is that we're leaning toward 2.100.

The beta for 2.099 [was announced on February 
17](https://forum.dlang.org/thread/vlyynedwupodqcytjptn@forum.dlang.org).

Martin later reported that he has worked on template emission in 
unit test mode. When compiling with `-unittest`, it used to 
behave similarly to `-allinst`, but now emissions have been 
significantly reduced. The best benchmark of ~20 projects from 
Átila showed a 36% reduction in memory usage and compile time. 
There are still some things that can be culled even more.

### Iain
Iain said the most productive thing he'd done over the previous 
month was removing ~5,000 LOC from DRuntime in the form of 
redundant bindings. Other than that, he agreed with Martin about 
the stable branch.

### Vladimir
Vladimir opened with a progress report. Back in December, [we 
discussed migrating our Bugzilla issues to 
Github](https://forum.dlang.org/post/wnnwxyjtizvhyswwqehz@forum.dlang.org). An alternative solution is to [upgrade to Bugzilla Harmony](https://github.com/bugzilla/harmony), a project Vladimir had been contributing to for some time. After that meeting, we agreed that Robert Schadek would move forward with implementing his migration script, while Vladimir would get the new Bugzilla instance set up so we can test it out in the interim.

Unfortunately, he reported that he has encountered a blocker. He 
needs the configuration files for our active Bugzilla instance, 
but the maintainer has so far been unresponsive. For now, he will 
continue working on Bugzilla and will keep trying to get the 
configuration files. (On a side note, this is one reason why we 
plan to get all of the services in our ecosystem under one roof 
with access for multiple admins. We're thankful for all of the 
work the volunteers in our community have put into maintaining 
services for us, but we've grown well beyond the point where we 
can live with having a single point of failure for every service 
in the ecosystem.)

### Ali
Ali reported that he finished his [Programming in 
D](https://ddili.org/ders/d.en/index.html) edits, saying that the 
physical book is updated as well.

### Razvan
Razvan gave us a report on the status of [the leaderboard for the 
Bugzilla rewards](https://bot.dlang.io/contributor_stats. He 
added asterisks next to the names of those ineligible to receive 
rewards, and he also added another page: 
https://bot.dlang.io/contributor_stats shows overall stats, and 
https://bot.dlang.io/contributor_stats_cycle shows the stats for 
the current cycle. He told us he was thinking of theming the page 
based on the DConf logo and colors from 2016/17 in Berlin, and he 
has since done so.

He also brought up the vision document.

In [the discussion thread of our September 2021 meeting 
summary](https://forum.dlang.org/post/yybthlissupxlgsgjupl@forum.dlang.org), I said the following in response to a question about the vision document:

> ...in the process of revising it, I realized it needs a 
> complete rewrite. The document we ended up with isn't what we 
> said we wanted.
>
> The rewrite will be a high priority for me once I wrap up the 
> DConf Online Q & A videos and get the DIP queue moving again

At the time of the meeting, I was still working on the last DConf 
Online video (the AUA), so I wasn't quite ready to turn my 
attention to it yet. I had intended at some point to propose a 
special meeting to discuss it, but since Razvan brought it up I 
suggested we hold that meeting on February 18. Everyone agreed. 
We did have the meeting, and you'll find a brief summary of it 
below.

### Átila
Átila had nothing to report.

### Mathias
Mathias brought up [a PR he had submitted to 
dmc](https://github.com/DigitalMars/Compiler/pull/13) a year ago. 
It adds CI. He asked if Walter could provide feedback on it. 
Walter asked him to send him an email with the link, and Mathias 
said he would do so as soon as he rebased the PR.

While putting together this summary, I followed up with Mathias. 
He has now rebased the PR, and I've sent Walter the link.

### Walter

**ImportC**
Walter told us how he thinks ImportC is going to be a big deal 
for D. He wants to get us "over the hump" with getting it working 
properly. He thinks his C extension to allow importing D files in 
C is working out far better than he expected, and he's 
considering proposing it to the C committee. The biggest 
difficulty with ImportC is compiler extensions that we either 
have to implement or give up on.

Walter asked Iain and Martin if they were going to implement 
ImportC in GDC and LDC.

Iain explained that it will be used when importing a C header 
into a D program, but any C files passed on the command line will 
go through the GCC driver and be handed off to the C compiler. 
Walter asked if GDC could get a command-line flag to bypass the 
driver and pass C files to ImportC instead of GCC, and Iain said 
that's not possible. He and Walter brainstormed ways to do it, 
but Iain said GDC has no control over the `main` function. He 
also noted that GCC is already a good C compiler, so he doesn't 
see a reason to bypass it.

Martin said you can currently import C headers and compile C 
source with ImportC in LDC, but he hasn't yet implemented the two 
new AST nodes that Walter implemented for ImportC in DMD's 
backend (initializer lists and bitfields). He hopes to handle 
those in the glue layer and output errors saying LDC currently 
has limited ImportC support. Implementing bitfields is going to 
take a bit of work.

Walter said he now thinks having the C initializers flowing 
through to the backend in a new AST node was a mistake. He plans 
to change the implementation so that the frontend semantic 
routines translate them into D initializers.

**Bitfields**
Walter then brought up bitfields in D. He had expected it was 
going to be an obvious, uncontroversial feature, and was 
surprised by the resistance to it.

The number one objection he's seen is that it would break the 
reflection API. He noted that bitfields will work with the 
reflection API without breaking anything (callers will get a 
field that is a union of the bitfields, so its address can be 
taken, and it will have a name derived from "bitfields"). We can 
add a traits feature that specifically fetches a bitfield.

Martin said he was satisfied with that solution, but wondered 
what would happen when taking the address of a bitfield. Walter 
said that would fail to compile. Martin feels this hurts the 
elegance of the language just for the sake of a rare case for 
which there has been no big demand and for which we already have 
a library solution ("not great", but it works). This went into a 
long discussion about opportunities for compression of data 
structures (particularly in DMD), whether or not that's 
beneficial for DMD, compatibility with C, library vs. language 
solutions, experience reports (Mathias described how his company 
handled bitfields in bindings not using the library solution), 
improving the library solution so that it's more elegant, the 
bitfield implementation in ImportC, C compiler bitfield layouts, 
and quite a bit more.

**128-bit integers**
Finally, Walter said he has looked at implementing 128-bit 
integers (cent and ucent), but implementing them in DMD would be 
a nightmare. After more thought, he has decided it's probably 
better to implement them as a library type. He mentioned how 
complex numbers were ripped out of the compiler and implemented 
as a library feature. The work that has already been done on 
`cent`/`ucent` will not be wasted, as it can still be built on to 
implement the library type.

### Max
Max on a whim began implementing the string interpolation of [the 
DIP under development](https://github.com/John-Colvin/YAIDIP) 
(not yet submitted) by Andrei and John. He asked if it's okay to 
go ahead and finish it up and put it behind a preview switch. 
Walter hadn't seen the DIP yet but noted that he was strongly 
opposed to any complicated string interpolation feature. The 
implementation of string interpolation should be easy to explain 
to anyone. Anything that is complicated to explain just isn't 
going to work. He will need to review the DIP before deciding on 
allowing a preview switch.

I suggested finishing the named arguments implementation should 
be a higher priority right now, and Walter agreed. Walter 
stressed that named arguments need to be interchangeable with 
struct initializers. We'll have to keep struct initializers 
around for backward compatibility, but he wants named arguments 
to replace them generally.


## Vision Meeting
The vision meeting took place on February 18 at 15:00 UTC. The 
following members attended:

Walter Bright
Iain Buclaw
Ali Çehreli
Max Haughton
Mathias Lang
Átila Neves
Razvan Nitu
Vladimir Panteleev
Mike Parker
Robert Schadek

One of the things we were missing from our initial conversations 
about the vision document last year was an overarching Vision 
Statement. This is the elevator pitch that describes where D is 
going. It isn't down at the level of specific details, but far up 
above. It's a broad, general statement about our long-term goals 
for the language. This will sit at the top of the vision 
document. While the rest of the document will change as 
priorities shift and tasks are completed, the vision statement 
should remain fairly constant. The more specific details in the 
rest of the document should all be there because they are sending 
us on the path described by the vision statement.

I asked everyone present to brainstorm. What do you want for D? 
Where are we going with it? If there were an end goal, what would 
it be? No idea, no matter how broad or how specific, was 
off-limits. The more information I have to draw from, the better.

Each person has their own ideas about the specifics of where we 
need to go, but I was confident we could find a consensus at a 
higher level. I'm not going to copy here every item on the list 
or summarize the entire discussion. The meeting lasted over an 
hour and we covered quite a bit of ground. However, many of the 
items fall under broader categories related to the usability of 
the language and the quality of the overall user experience 
(i.e., the ecosystem, Phobos).

I haven't gotten to it yet, but the next step is on me. I'll 
draft three or four different vision statements, then we'll hone 
in on something that makes us happy. Once we have that, I can 
start assembling the details for the rest of the document. My 
current plan is to lay it out in three sections:

**Current Focus**: This describes where Walter and Átila are 
currently directing their attention and what their end goals are. 
It also serves as a guide for volunteer contributors looking to 
fix bugs or make other contributions, e.g., bug categories 
related to Walter and Átila's work, suggestions for how to test 
related language features, ideas for projects that can help reach 
their end goals, etc.

**Future Focus**: This describes possible directions toward which 
Walter and Átila would like to turn their attention in the 
future, also with suggestions for volunteer contributors. Those 
who feel their skills are better applied toward one of these 
areas than those of the current focus can do so knowing that 
their work will move us toward the desired goal.

**Wishlist**: This is a grab bag of ideas ranging from small 
tasks to large projects. Some of them will be things that would 
be nice to have, but that Walter and Átila will never have time 
to work on. Some may be important tasks that don't fit into the 
broader focus categories above, things that either Walter or 
Átila will have to do at some point if no one else does. Some of 
these may be set up as paid contract work.

I can't say with any certainty how long it will take us to get 
all of this together. I know many in the community are eager to 
see it. Speaking for myself, it's not my highest priority at the 
moment. I'm sure that's true for everyone else whose input will 
be required to get to the final version. But I *am* making sure 
it gets done, step-by-step, section-by-section. My loose goal is 
to have it completed before DConf.

## The Next Monthly Meeting
I'm quite late putting this summary out, so it's already almost 
time for our next meeting. We're scheduled to hold it on March 4 
at 15:00 UTC. I plan to put forward a proposal about the next 
step in getting our services under one roof with multiple admins. 
If you have an idea or issue you'd like to bring to us at this or 
a future meeting, please contact me at social at dlang.org and I'll 
see about getting it on the agenda.