Permalink
Reply
The D Language Foundation's monthly meeting for August 2023 took place on the 11th. At just under 35 minutes, it was our shortest monthly meeting to date.
The attendees
The following people attended the meeting:
- Walter Bright
- Ali Çehreli
- Martin Kinkelin
- Dennis Korpel
- Mathias Lang
- Átila Neves
- Mike Parker
- Adam D. Ruppe
- Robert Schadek
- Steven Schveighoffer
The summary
Me
I had nothing new, other than to say that DConf planning was on track.
Adam
Adam had nothing for us this time.
Robert
Robert said he was happy. Dennis asked if the compiler was fast enough (as regular readers of these summaries may know, Robert often says the compiler is too slow). Robert said it's still slow. He just wanted to see LSP support in the compiler and take all the good things.
Walter noted he'd been working on improving compilation speeds. He'd realized that the compiler was being compiled with exceptions, so he'd been working on making it compile without exceptions to see what effect that had on speed. It might be a small difference, but every little difference helps.
Adam said his library compiled in half a second. Robert said that was still too slow. His work project didn't compile in half a second. He said his goal was that by the time of the key-up event after pressing 'Enter' on Ninja or whatever build tool/compiler he's using, it should have already restarted the application. Átila agreed that half a second was too long.
Adam brought up D1. An old game he wrote back in 2007 compiles and links in 10 milliseconds. If you looked at a big chunk of the difference between D1 and D2, object.d back then was around 600 lines. Now it was much bigger, and that adds up. Walter said that he was a bit upset with the state of object.d. It was supposed to be a minimal thing and had turned into a kind of garbage dump somewhere along the way.
Steve
Steve said that Dennis had been doing a fantastic job with his PR on the compiler part of static associative array initialization. Steve thought it was about ready to go if someone could push the button. He didn't want to be the one to push it, because he didn't know the compiler code very well and couldn't vouch for its correctness. (The PR is still open as I write.)
Dennis
Dennis said he'd been working on that AA PR, but had nothing else to report. He still had some other things to pursue, like looking at pattern support for the deprecation (-d/-de/-dw) and obsolete warning (-wo) switches, as well as the standalone attribute or pragma for static constructors.
(In our July monthly, Adam proposed a means to annotate static constructors that could make them independent of cycle detection. In a subsequent planning session, we agreed to implement it. Since the August meeting, Dennis has submitted a PR for the @standalone attribute, but in the PR discussion thread, Walter thinks it should be a pragma.)
Martin
Martin said the bump to version 2.104 of the frontend went well on the LDC side and was quite painless.
Next, he had an interesting side note inspired by a forum post he'd seen about getting LDC to work on a 8-bit AVR platform. He'd looked into it and found it an interesting question in terms of whether and how we want to support architectures with pointer sizes less than 32 bits. Currently, the frontend has a hard-coded limit: size_t and ptrdiff_t are either 32 or 64 bits, nothing lower than that. It's a frontend check, and the definitions in DRuntime directly depend on the compiler's internal type because they use the typeof expression.
He had tried to make the frontend accept 16-bit and 8-bit size_t and ptrdiff_t, but doing that bumps up against the integer promotion rules. The promotion rules can work in some specific cases when using a smaller int, but when you have something like the length of a slice and do a little plus one or minus one, that's a problem. You need to cast it. So either we need to change dealing with the promotion rules in this regard, try to mimic C++ in this regard, or hopefully do something better. He said Adam had proposed something in a past discussion that would handle it generically so it's still target independent.
Walter wondered if Rust supported less than 32-bit compilation and what compromise they made for that. Martin said he wasn't sure. He'd only checked C and C++. Robert looked it up and found that Rust has a tiny bit of support for 16-bit MSP340, but it's a big asterisk and everything else is 32 or 64.
Martin wasn't sure if it was even worth looking into these architectures, because he had no idea how long they'd be around. For low power consumption, even if you're playing a few years ahead, he thinks it's going to be 32-bits even for those very small and power-efficient sensors, or whatever. But he couldn't look into the future, so he had no real idea.
Walter said when he'd designed D, he thought 16-bit architectures were dead and everybody would be using embedded 32-bit processors. But that was a huge simplification. There was so much trouble in C from the ints not being a predictable size. Just endless problems with it and suffering because of it.
Mathias
Mathias had nothing to report.
Ali
Ali had mentioned in our July quarterly meeting that his company (Mercedes Benz Research & Development North America) was looking for a D programming intern. He'd since contacted Mike Shah at Northeastern University. As an example of industry/academia collaboration, Mike had recommended a strong candidate, and the company had already hired him. They planned to bring on another intern who comes with a good recommendation. So the D team is increasing to three people.
Ali wanted to expand his team to be more like a tools team, like a wildcard team working on multiple different things inside the company. The new candidate agrees. So they were expanding and they were working on something he couldn't yet provide details about.
Átila
Átila had been busy with Symmetry stuff, so had nothing to talk about this time.
Walter
Walter said he'd thought about Robert's observations that until we have the compiler as a language server or a library, we're going to be in trouble. So he'd been going through the compiler frontend and fixing it so that it's much more amenable to having DMD as a daemon.
He'd made quite a number of changes for that. Some of the PRs were still sitting there, waiting to be pulled. The idea was to look at the subsystems of D and remove their dependencies on global state, and dependencies on the environment and the operating system, so that they have a simple entry point where one function takes all the parameters it needs, does its operation, and returns data. Then the caller can decide whether to write a file or what to do with error messages, and so on.
He said that work was kind of satisfying when he got a piece set up like that. The error sink had been his first attempt in that direction. The lexer and parser were now capable of being divorced from the rest of the compiler and are restartable. It also means the LSP daemon or whatever will be able to be multi-threaded, because you can be doing multiple compiles at the same time with this setup. He's still got a ways to go, but it's proceeding.
He was also looking at redefining the interface to the glue code, so that should make Iain's and Martin's lives a little easier. Martin said he wasn't so sure. He thought the interface in its current state was absolutely fine.
Walter said he'd submitted numerous PRs to remove all of the external dependencies from the documentation generator, and that was getting close to being done. He had separated out the macro processor so that it was now standalone. That's the sort of thing he'd been working on.
He saw this as a sort of existential thing for D. He had come around to Robert's point of view and felt it was important to get this moving. Razvan wasn't in the meeting, but Walter was curious about his thoughts about all of this since he'd been working on DMD as a library. He asked Robert if the work needed for both DMD as a library and the LSP server was the same.
Robert said DMD as a library is a big building block to build the LSP, but there was more to it in terms of building a server that takes commands, runs the compiler, and returns the information as JSON. The compiler library is a big part of that. His fingers were crossed that the rest was just glue. He thanked Walter for working on this. Walter said Robert should be thanked for making the observation that gave him the impetus to get this done and realize its importance.
We then fell into a bit of side chat for a few minutes about GitHub handles vs. real names and how confusing it can be when they differ, and how the programming world had changed in terms of new programmer expectations.
Then Walter thanked Steve and Dennis for working on the static AA initialization. For a long time, he'd thought it was completely impractical. Steve had convinced him it could be done reasonably. It was a nice improvement that didn't need anything different because it was just turning on something that hadn't worked.
Steve said there was a note in the spec saying this was an intended feature that wasn't implemented, so we could finally remove that. He said that Dennis was doing a great job. He sometimes felt that every time he brings up something that's wrong, Dennis has a PR to fix it a day later.
Finally, Walter had a question for Mathias about -preview=in. He remembered that we had discussed in a meeting that the feature should always pass by reference, but when he looked at the implementation, he found that it hadn't been changed. It was still taking the original approach of passing by value or by reference depending on the case. Mathias remembered this conversation and that we'd agreed to change it, but he had just never gotten it done. He said he remembered Martin saying he'd keep the current behavior for LDC. Walter asked if Mathias wanted him to make the change. Mathias said he'd do it, and he'd do it in a way that didn't prevent LDC from doing what they want.
Walter recommended Martin make the change for LDC, as there was a solid reason for the change. Martin said they'd have to disagree on this point. It was a feature he would have loved to see 10 years ago, and he was very happy Mathias had implemented it. He wasn't going to dump it, but he would probably put it behind a switch to enable or disable it. It wasn't ideal, but he liked this feature very, very much.
Walter said it was a reliability issue. If it's always by reference, it's predictable behavior. He thought it was extremely important to have predictable and portable behavior. Martin reminded him they'd had this discussion quite some time ago. He was still of the strong opinion that once you regard every such occurrence as a reference, or treated it like it should work for a reference, too, but don't depend on its identity, you're fine. And that's 99.99% of all code. And it was a very nice performance thing. He didn't know of any other language having such a feature. For LDC, it was going to be well-defined. Not implementation-defined, but target-dependent.
Mathias said that he agreed with Martin. However, it was fine to just make DMD always pass in parameters by reference. That was the best compromise we could come up with when we last discussed it.
Ali wanted to confirm that this feature solved the problem with rvalue references. If you want to accept rvalues, you just use in. Mathias said it did.
Mathias said he'd seen that the only thing preventing preview in from being finished was a bug in the frontend that is tied to another bug that is unrelated to preview in. It wasn't an easy one. It was something to do with CTFE, but he hadn't had the time to dig into it. So it was still blocked on that. He said it was well-defined, he just needed someone to unwind the issues. Dennis said he would look into it.
Martin thought that issue was blocking one of his old PRs. He couldn't remember which PR, but he was sure it was the same CTFE issue. The problem was that temporaries in statements in CTFE don't get destructed at all. There was a chorus of "That's bad". Mathias said that getting the same destruction behavior as runtime is not trivial.
Walter said he could see that was going to be a tricky one. The CTFE engine was a horrible mess.
Dennis wondered if this would break code once destructors started running in CTFE. A lot of destructors just call free. Martin noted that any destructor calling free would be calling it on something that had to be malloced first. And that wasn't doable at CTFE either. The current behavior of just silently skipping all of the destructors was as wrong as it could get. It couldn't be any more wrong.
Steve said that if you were going to run free in a destructor in a type that's going to be used at CTFE, you'd already have an if(__ctfe) branch to account for that where you call malloc. You'd have the same in the destructor. This is nothing new.
The next meeting
As we wrapped up, I asked if we should have a planning session on the 18th. It was our only real opportunity to have one before DConf. But given that most of us had stuff going on preparing for DConf, or were already traveling, I suggested we not do it. But I left it to the group to decide, and we decided not to do it. In a previous planning session, we'd decided to hold a session at DConf to start talking about long-term plans, so that's our next one.
Our next monthly meeting is going to be on either September 8th or 15th. We'll figure that out at DConf next week.
