Permalink
Reply
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 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:
- The moderators have full discretion to remove posts and ban users as they see fit.
- 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. 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. 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. 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.
