D Language Foundation May 2024 Monthly Meeting Summary

[Mike Parker]

The D Language Foundation's monthly meeting for May 2024 was held 
on Friday the 10th. It lasted about an hour and 30 minutes.

## The Attendees

The following people attended:

* Walter Bright
* Jonathan M. Davis
* Timon Gehr
* Martin Kinkelin
* Dennis Korpel
* Mathias Lang
* Átila Neves
* Razvan Nitu
* Mike Parker
* Robert Schadek
* Steven Schveighoffer
* Adam Wilson

## The Summary

### Item 1: Deprecating operator overloads in Object

Steve wanted to discuss the implications of deprecating 
`toString`, `toHash`, `opCmp`, and  `opEquals` in `Object`. He 
brought this up after seeing [a post from 
Átila](https://forum.dlang.org/post/xwkithpcwnltfpvsyxft@forum.dlang.org) in a forum discussion on the topic, in which Átila had said:

> I talked to Walter and we agreed that the best way forward is 
> probably to deprecate these member functions and remove them in 
> the next edition.

I failed to record about half of the conversation, but I did 
catch the important bit. The idea was that we would have a 
`ProtoObject` similar to the one previously proposed, or whatever 
we wanted to call it, that did not contain the overrides. It 
would become the new root object in code compiled under the new 
edition and would be part of the `Object` hierarchy in legacy 
code.

Steve explained that it was supposed to be possible to compile 
libraries using two different editions, but they must be compiled 
with the same compiler. So the compiler would be aware of these 
two different root objects and the two different hierarchies. He 
just wanted to make sure we all agreed that we couldn't just 
remove members from legacy objects. He thought managing the 
runtime library would be the trickiest part with editions.

Martin thought it was going to be weird having these different 
hierarchies, but then as he was talking about it he realized that 
with the proto object deriving from `Object`, it might really 
work. Timon said that the new edition's object was `Object` 
without the methods, and the `Object` in the old edition was 
implicitly rewritten to legacy `Object`, and in new editions, you 
could refer to that implicitly.

Jonathan noted that we'd talked in the past about wanting to 
remove the monitor from `Object`. The proto object would allow us 
to do that. He said we should also look at whatever else we 
wanted to clean up in `Object`.

### Item 2: Forum moderation

Steve said we'd recently been visited again in the forums by 
someone who periodically returned with sock puppets, and that had 
gotten him thinking about forum moderation. There were a couple 
of ways he thought we could improve it.

First, he thought it shouldn't just be me doing everything. It 
would be better if we had a team.

Second, he wondered if we could be more transparent about 
moderation. He knew we were running Vladimir's custom software, 
and he noted that I'd mentioned in the forums that there was no 
way to restore a deleted post because, ultimately, it was the 
NNTP interface backing everything. He wondered if we could put a 
layer of moderation tools on top of that.

Finally, he suggested we should have some moderation rules, even 
if they were very vague.

I agreed that we should have more people moderating. When I 
signed up, I didn't realize I was going to be the only one doing 
it. A big problem was my time zone. Sometimes, I woke up and 
didn't check the forums until late morning or early afternoon my 
time and discovered something had blown up in the interim.

I said I also would love more forum moderation tools. I would 
love to move away from the NNTP interface on the back end. It was 
2024, after all. We should have a trash bin that stored deleted 
posts so that they were recoverable. Then if somebody wanted to 
appeal, we could have a process for that. We could have time-outs 
and more. With those kinds of tools, we could be more aggressive 
in good conscience.

As far as rules, I said that I'd been around forum communities 
for 30 years. In my experience, in forums without rules, people 
sometimes complained about the lack of rules, but then in forums 
with rules, they argued over which rules were there. In the end, 
I didn't think it mattered if we had rules or not. I thought 
there were only two sensible forum rules we could have anyway:

1. The moderators have full discretion to remove posts and ban 
users as they see fit.
2. All decisions are final.

Those were the only things that made sense to me because they 
covered all the bases. There was no room for argument. There were 
no loopholes. Moderation was inherently subjective, inherently 
arbitrary, and inherently biased. For example, I'd give a lot 
more room to Steve if he went on a temper tantrum than I would to 
one of the sock puppets.

I noted that when Walter and I were having our coaching sessions 
with Saeed from Ucora, we'd come up with this idea of having a 
kind of philosophy rather than a set of specific rules. Not just 
about the forum, but the community in general. It was inspired by 
the honor system that Caltech had when Walter was studying there. 
Just a general philosophy about the kind of community we wanted 
to foster. Forum posts that went against that would deleted.

I asked that anyone willing to become a forum moderator please 
let me know.

Steve said that a good reason to have a set of rules was when you 
had a team of moderators. Then they'd have something they could 
agree on.

I said that made sense, but I could give an example of what could 
happen in that situation. I was in a forum once where the 
maintainers established a set of specific moderation rules that 
everyone was constantly arguing about. It evolved into "yellow 
card" rules that were appealable and "red card" rules that were 
not. And the list of red card rules just kept growing as they 
plugged more and more loopholes. It was a mess.

So I thought specific moderation rules were not the way to go. 
The other thing was that as moderators, Steve and I might have 
different red lines. Those were going to be gray areas where we'd 
never agree. He might delete a post I wouldn't have, or I might 
approve a post he wouldn't have. We should agree to back each 
other up in those cases, and any moderation guidelines we might 
come up with should account for that.

I asked who wanted to join me as moderators. Steve and Dennis 
both volunteered. Átila noted that covered all the time zones.

Razvan said he'd be happy to help, but wouldn't want to make 
moderation decisions. He'd prefer instead to flag posts for 
moderation. Steve noted that the forum software did have a link 
to flag posts (not visible to everyone) that was a little 
underdeveloped since it didn't allow you to specify the reason 
you were using it. He said he'd typically only flagged spam. If 
people were being argumentative, he felt the best solution was 
just to ignore them.

I said the general rule I'd been trying to follow was that if 
someone lobbed a blatant personal insult in a post, I didn't care 
what other information was in it, I'd delete it. Sometimes I'd 
see things that weren't blatant insults but tingled my spidey 
sense. Something close to the line for me, but not across it, 
though it might cross it for someone else. In those cases, I 
would wait and see. If the target of the insult then reached out 
to me to complain about it, in the past I'd often try to persuade 
them to let it go since I didn't see it as an insult. These days, 
I was more likely to delete the offending post. No questions 
asked.

Another thing I looked for was if a post was disruptive to a 
thread. What I considered disruptive or not, other people might 
consider the opposite. So if I started getting emails about a 
post that I initially let pass, I could say, "Okay, it's 
disruptive.".

We then devolved into a bit of discussion about the forum's spam 
filter, the types of spam we get, and so on, before moving on to 
the next item.

(UPDATE: Vladimir set up both Steve and Dennis as forum 
moderators a few days later. They've been working at it since. 
It's nice to have the extra hands and eyes, so thanks to both of 
them for stepping up.)

### Item 3: Walter's & Atila's DIPs in the new DIP process

When I announced the new DIP process, the one thing I hadn't yet 
worked out was how to handle DIPs from Walter and Átila. I 
believed that if Walter wrote a DIP and could persuade Átila to 
approve it, that should be enough, and vice versa. But I 
remembered the big community blowup over the safe-by-default DIP 
and how we responded to that by requiring Walter and Átila to 
find someone else to take on their DIP ideas. We'd since decided 
that was a mistake, but I didn't want to make an arbitrary 
decision myself about how to handle their DIPs in the new process.

Walter and I had spoken about it and we wanted to get input from 
the rest of the team. I asked for their thoughts.

Jonathan said he wasn't sure what should be done in terms of 
approval, but he thought it was important that Walter's and 
Átila's proposals were submitted for community feedback. I said 
that was a given, and that Walter had two DIPs in the development 
forum at the moment. That was why this was coming up now.

One of the posted DIPs was [the bitfields 
proposal](https://forum.dlang.org/post/v193hc$b9c$1@digitalmars.com). It had received a good bit of opposition, including from people in the meeting. The other DIP was the one proposing [ref for variable declarations](https://forum.dlang.org/thread/v11mh1$fvs$1@digitalmars.com). It wasn't controversial. Should he and Átila approve it, then no big deal. But what about the bitfields DIP? If they approved that, would we have another blowup?

Steve didn't think the bitfields DIP was as controversial as the 
`extern(C)` functions being safe by default, which was the source 
of the blowup over that DIP, because not many people were using 
bitfields. He thought Walter's concerns were a non-issue as 
nobody would care. The penalty would be that we'd just inherit 
all of C's problems with bitfields.

Martin said it wouldn't just be that. The one thing he didn't 
like was that we'd lose the ability to take the address of any 
member. That would be an ugly special case.

Steve said his point was that there wasn't a whole lot of code 
out there that was suddenly going to be broken. You'd have the 
choice not to use bitfields. So he thought maybe people weren't 
going to like it, but they weren't going to use them either.

I noted that I wasn't asking what to do about any specific DIP 
but about DIPs authored by Walter and Átila in general. What 
should their assessment look like?

Steve said he didn't know of a way to do it other than having 
someone else with veto power involved to avoid the situation with 
the safe-by-default DIP. It wasn't like there wasn't feedback on 
that one, or that there wasn't complete disagreement between the 
community and the maintainers, and they approved it anyway. He 
didn't know how you could fix that. He didn't think it was the 
DIP process, just that that specific DIP was controversial.

Átila said they had walked it back anyway, so he wasn't sure 
anything failed in that case. Steve said that was true, but he 
didn't know if there was something we could do with the process 
to prevent controversy.

Timon said he didn't think the safe-by-default DIP was 
controversial in its entirety. There was just one aspect that, in 
his opinion, had an easy fix that Walter didn't want to 
implement. He instead decided to revert the decision. In the end, 
it wasn't an issue over breakage, it was just about having 
`extern(C)` functions be safe by default.

He said that going forward, accepting a bad DIP would be less 
consequential than it had been in the past once we had editions. 
In the worst case, we'd have one thing more to maintain in an 
intermediate edition before it was fixed. Maybe that was a 
calculation we could take into consideration. Átila said that was 
a good point.

I said I just wanted a solution. Razvan had made a point to me in 
one of our conversations that when someone from the community put 
a DIP forward, they had Walter and Átila as counterweights. They 
were there to temper it and tone it down after all the feedback 
to make the final decision. But if it was just Walter or Átila 
putting a DIP forward, they each had only the other as a counter. 
Did we need more than that? Did we need to set up something more? 
That was what I was looking for feedback on.

Razvan believed we did. There should be a mechanism of oversight 
for everyone submitting a DIP. Even the language maintainers 
could get it wrong, so we needed someone to point that out. Átila 
said that should be him, but maybe we could just pick one of the 
team members to be a second counter.

Razvan noted that his original suggestion to me was that we 
should have some sort of committee. It could be two or three 
people we trusted with this. If it were just one person, to the 
community it might look like Átila could just give two beers to 
Walter to get his DIP approved. Átila joked that that would be a 
lot more effective on him.

Walter said he wanted to avoid what had happened with the C and 
C++ committees. He felt they had lost their way with the features 
they were adding and approving. He said they'd approved some 
baffling stuff, like C identifiers that were normalized Unicode 
identifiers. And C++ had implemented modules in a completely 
wrong and ridiculous way. And they had a new library function 
called std::launder. He said that he laughed every time he heard 
a description of it, then forgot what it did.

He said that when the C++ committee first formed back in the 90s, 
he'd heard members say things like, "I'll vote for your feature 
if you vote for my feature." He felt that kind of thing had led 
to incredible complexity in the language.

I said that wasn't the case here. What Razvan was proposing 
wasn't a committee that made proposals, but a committee that just 
acted as a counter for proposals from him and Átila.

Átila said that either the committee should be the people in this 
call, or that I should pick someone to be the second counter.

Robert said he had thought something similar. We should just go 
round-robin or random selection. When Átila put a proposal 
forward, we could select one of us who wasn't Átila to assess the 
DIP with Walter. And if the chosen person didn't have the time or 
felt they didn't have the expertise, they should bow out and we 
would go a second round with a shorter list.

Razvan thought the point here was to avoid the situation where an 
overwhelming majority of the community felt that a DIP by Walter 
or Átila shouldn't be implemented. So we could just have a 
discussion about that particular DIP in one of our meetings, and 
then vote on it. If you felt you didn't have the expertise, you 
didn't vote. Then it would also be on Walter and Átila to agree 
that they would accept the result or modify the proposal to sync 
it with expectations.

Átila said that would be okay.

Walter asked if everyone remembered his string interpolation 
proposal. There was just him, and then everybody else. It was a 
pretty painful thing for him, all the arguing about it. He didn't 
like what happened, but he eventually threw in the towel on it. 
He couldn't fight everybody on it. He still thought it had been a 
bad idea to give up, but he accepted that the community wanted a 
different approach.

It had been him against the world, and he'd given up. So it 
wasn't the case that he could just override everyone in the 
community. It may work in theory, but it didn't work in practice. 
He'd given up on other things, too, over the years. He still 
seemed to be the only one who thought `@live` had any value. He 
thought the jury was still out on that, but he wasn't confident 
it would survive.

Steve said he thought it was important that anyone involved in 
assessing a DIP should be as neutral as possible. You didn't want 
someone deciding on it who was adamantly for or against it. They 
had to be able to look at the arguments objectively. That was 
kind of the point of not having Walter or Átila as the author 
involved in deciding. They'd be so close to it that they might 
not see the drawbacks.

I said that I was uncomfortable watering down Walter's authority 
as a language maintainer even when it came to approving his own 
DIPs. What if instead of having the team vote for a DIP, we sat 
down to identify critical flaws that would cause problems down 
the road and hash those out? I didn't know what that would look 
like, though.

Robert said it was like we were trying to discover a new 
government form next to democracy. When Walter was talking about 
how it was him against the community on certain issues, Robert 
had the thought that D is much more now than just something on 
Walter's computer all those years back. It had a growing 
community and was used, loved, and hated by a whole slew of 
people. A benefit was that Walter got to go to DConf and have a 
good time, but it also meant that he lost some control. Robert 
wasn't sure that could be avoided. He understood how Walter could 
get uncomfortable with it, but felt it was par for the course.

He said whether we went with voting in our meetings, a committee, 
or having one or two people sit in to decide when needed, it had 
to be Walter's decision to abdicate some of his power. It wasn't 
like we were a community of 80 million people. He worried about 
coming up with a detailed DIP process trying to account for all 
kinds of caveats. At the end of the day, we had to trust whoever 
we elected to evaluate Walter and Átila's DIPs, even when we 
disagreed with them. We just had to agree to disagree and move 
on. He felt we weren't going to find "perfect" here.

Steve felt whoever we picked should handle things via 
face-to-face discussions rather than via forum posts or emails. 
It was too hard to read the context and emotions involved in text.

Adam said that one of the reasons people brought things to him in 
Discord was because they knew he'd be sitting in front of Walter 
for an in-person discussion. He said it had been a bit 
frustrating at times because he didn't always get their points 
across the way they wanted, but even in those cases he was often 
able to get to a point where Walter would say, "Okay, I'll have 
to think about that." So there was something to be said for 
face-to-face communication.

We got sidetracked a bit here talking about instances where 
disagreements had been solved via video calls, conversations at 
DConf, and in other face-to-face scenarios, then Walter suggested 
that if a DIP was controversial, then we should have a meeting 
about it to work it out. The person carrying the flag for it 
should be involved, and then we could argue this way and that 
about it. Arguing about it in the forums was never going to work 
and only resulted in hurt feelings.

I said doing that for controversial DIPs was fine, but the issue 
at hand was about doing something like that for his and Átila's 
DIPs. I proposed that instead of picking one person to serve as a 
second counter, we could have a group meeting with the regular 
team. We could get together, then I'd ask if there were any 
objections to moving a DIP forward, and we'd go from there. The 
goal would be to resolve any objections one way or another. If 
they were resolved in the author's favor, the DIP could go 
forward. If not, it didn't get approved. Then if coming out of 
that, the DIP ultimately was approved and any controversy arose, 
we could explain whether any objections were raised and, if so, 
how they were overcome. The point would be that the whole team 
would be behind it if it went forward.

I asked if everyone was okay with that. There were no objections.

### Addendum: Walter's two DIPs

I next asked if anyone objected to either the ref DIP or the 
bitfields DIP. I wanted to know if we needed to call a special 
meeting to handle either DIP or to determine if any objections 
were simple enough to handle in the time remaining in this 
meeting. There were no objections to the ref DIP, but Timon and 
Steve indicated they had objections to the bitfields DIP. They 
had already brought them up in the forums, but I asked them to 
voice them here to see if we could deal with them.

This started a discussion that lasted close to 30 minutes. I 
won't walk through the entire thing here, as ultimately the major 
objections had already been aired in the three review threads in 
the DIP Development forum. The two biggest ones were that we 
should specify a layout for bitfields and require `extern(C)` on 
any bitfield that was dependent on the layout in the system's C 
compiler implementation. Walter believed that we didn't need to 
specify a layout and that it was perfectly fine to rely on the 
system C compiler implementation. We were already doing that with 
things like struct layout anyway.

Additionally, Martin reiterated his objection that we'd lose the 
ability to say that every member of an object was directly 
addressable.

At some point, I cut the conversation off and proposed we hold a 
separate meeting to discuss the bitfield DIP in detail. Everyone 
agreed.

(__UPDATE:__ Given that no objections were raised to Walter's ref 
DIP, it became DIP 1046 and I submitted it to Átila for 
assessment. He requested one clarification [and then approved 
it](https://forum.dlang.org/post/xyppgndgxdjyqtftfjgd@forum.dlang.org). The meeting regarding the bitfields DIP went well, overall. The consensus was that there was no objection to the DIP in principle, just disagreement over the implementation details. We talked about several potential issues with bitfields, including layout, alignment, immutability, taking an address, etc. In the end, Walter agreed to make a few changes to the DIP and to test the implementation with a serialization library to see how it holds up before deciding if the DIP should move forward.)

## Conclusion

On May 18, we had a small planning session with Rikki to discuss 
his DIP 1045, then we had the bitfields meeting on May 25. Our 
next monthly meeting was on June 14.