Permalink
Reply
The D Language Foundation's monthly meeting for July 2023 took place on the 14th. It lasted roughly one hour and forty-five minutes. John Colvin, who has participated in several quarterlies representing Symmetry, joined us for the first time as a permanent member of the monthlies.
The attendees
The following people attended the meeting:
- Walter Bright
- Iain Buclaw
- Ali Çehreli
- John Colvin
- Dennis Korpel
- Mathias Lang
- Razvan Nitu
- Mike Parker
- Adam D. Ruppe
- Robert Schadek
- Steven Schveighoffer
- Nick Treleaven
The summary
Me
I opened with an update on DConf preparations. I had been able to compile a solid estimate of how much we'd need to pay out in travel & lodging reimbursements. The total allotted for reimbursements from Symmetry's budget coupled with the revenue from registrations and additional sponsorship would be enough to cover it all. I was optimistic that we'd be able to make enough room in the budget for some catering upgrades.
(I can now say that we were able to get two upgrades to the breakfast selection and one for lunch. At this point, we're expecting around 75 attendees.)
Adam
Standalone static constructors
(First, some background. At one point during the June monthly meeting, we got off on a tangential discussion about cycles when running static constructors. Essentially, static constructors can get into a circular dependency situation when other modules are imported and execution will abort with a "cycle detected" error even if the constructor itself has no dependencies. Adam suggested a couple of approaches to solving the problem. To get us back on topic, I proposed we put it off for a future meeting. I then followed up with Adam and he gave me a short proposal showing what he had in mind. I emailed the proposal to everyone before this meeting.)
Adam proposed that we introduce a new annotation that can be used on static constructors to tell the compiler that they have no dependencies. Then the compiler could add them to a separate list for which cyclic dependency checking is turned off. Walter said we already had a mechanism for that in the form of pragma(crt_constructor), which designates a function to be executed by the C runtime during startup. Adam reminded Walter we had discussed this last time. The problem with that is that CRT constructors are executed before DRuntime is initialized, so any static constructor that depends on DRuntime can't be a CRT constructor.
Walter asked how this could be implemented. Adam said that the implementation for it is already in DRuntime. Steve clarified that the compiler can decide in certain cases that a standalone static constructor will not participate in cycle detection. Those constructors are not required to run in any specific order, so they're handled separately from those that are. That's what Adam was referring to. Since we already have a way for the compiler to flag standalone static constructors, he was just asking for a way that the user could tag a static constructor as standalone to go onto that same list.
Walter said he had recommended to people in the past that the way to avoid cycle detection on static constructors is to put them in their own module with no additional imports. Then they'll be standalone. Adam said that was unrealistic. Walter said his resistance to Adam's idea was rooted in a reluctance to change the language to do things that can be done, maybe not perfectly but at least reasonably, in other ways. Also, did we really need this? Not this feature in particular, but any we consider. Because if not, the language becomes full of clutter. And that's not good for any of us. Is there any way we can do this without adding a new feature to the language?
Walter also noted that allowing people to do this would add a bit of unsafety to the language. They may be mistaken about whether a static constructor has dependencies. It may work on one system and break on another because there would be no guarantee on the order in which it's run. The whole idea behind the ordering of constructors is to remove the responsibility from the programmer of trying to figure out in what order they are going to run when he may have no idea in what order they need to run. At the very least, such a feature would have to implicitly be @system. So are there other ways to do this? Are they reasonable or unreasonable?
Walter then asked how many times Adam had found a clear need for standalone constructors in a program. Adam cited his "JNI interop thing". It generates other static constructors to register classes with the Java runtime. That's an independent thing, but because it's done by a mixin it can't be set off in its own module. So if you were able to mark it as independent, you could avoid cycle detection.
Walter wanted to know why putting the mixin in a separate module would be a problem, and then the conversation got a bit confused. Aside from that, Steve emphasized that having all these extra little modules everywhere just to avoid cycle detection makes the code more confusing to read and makes the language less appealing. At that point, it seems like static constructors are useless.
In the end, Walter said he wanted to reserve judgment until he could see some example code. I told Adam and Steve I'd follow up with them to get some examples from them and go from there.
(Once I had the examples in hand, it was clear we were missing some context in the meeting. The mixin Adam referred to was intended to be used to implement static constructors inside classes, not at module scope, which made it impossible to put them in standalone modules. I put the issue on the agenda for our next planning session and emailed the participants the example code. In the end, Walter gave the thumbs up as I describe in my July 2023 planning update.)
Docker images
Next, Adam had a couple of issues people had asked him to bring up. The first was about Docker images being available under the dlang-community umbrella. There is a dlang-china repository that has reasonably up-to-date things. Some people had proposed that we fork that into the dlang-community repository and then periodically re-sync it from upstream. Then if they ever stop maintaining it, we'll have the fork that other people can start contributing to and using.
I noted that the DLF has nothing to do with the dlang-community repo. That's maintained by members of the community. I have admin access, but I don't do anything with it. I thought Jan Jurzitza (aka WebFreak) was the primary maintainer, so suggested that's who Adam should ask.
(I have since learned that Jan is not the primary maintainer and didn't even have full admin access. Regardless, any decisions involving the dlang-community organization should be handled by the people who regularly maintain it.)
LTS compiler version
Finally, Adam brought up recent discussions in the forums about an LTS (Long-Term Support) compiler, specifically the thread Grim Maple started. He said some community members had proposed that we designate GDC as the LTS version of D. So when someone goes to the website, the first thing they see is, say, GDC 12.1, and that corresponds to DMD 2.xxx and LDC 1.xxx, and that would be advertised as the LTS version of D. And we'd encourage the library maintainers to make sure they target that. Then the latest compiler releases would be underneath that on the download page as the development preview or something. So none of the processes would change, per se, but we market that GDC version as the version we recommend, and the others are marked as experimental in some way.
Walter said that would be up to Iain. Iain wasn't clear why it would be his responsibility to decide what should be the official LTS D compiler. Robert said if we do that, then we're just saying that DMD is a toy. I noted that GDC doesn't officially have any Windows releases.
Iain said that as soon as GCC puts out a major release, at that point there are no more feature updates to the D language that go into GDC. However, during that three-year cycle, there will be regressions and bug reports against specific versions of GDC. If they're being fixed upstream, he'll backport those so that they come into the next minor release of GCC. The only way he could see that working where the upstream is still DMD is if there's some cooperation with whoever wants to maintain those branches in DMD as well. Maybe LDC could help as well, so that we have a common place where to say, okay, this branch is where all bug fixes for this release are going. Otherwise, as soon as GCC makes a major release, his local copy is no longer downstream of DMD, but becomes a fork. And he maintains it as a fork. It's really separate.
Iain said the only way that DMD users would get the effect of an LTS release is if there's a branch in DMD upstream that's actively maintained, and he wasn't going to be the one maintaining that. Walter said that if it wasn't Iain, then it wasn't going to work. The whole idea behind an LTS release is that someone has got to do the work to merge the bug fixes and run the test suite on it. And if we don't have that, we can't just declare an LTS.
Adam said that wasn't necessarily the case. As long as the libraries keep working, even if it's a frozen version that's just not changing anymore, it's more about wanting third-party libraries to agree on some version. So you're not downloading one thing that requires DMD 102 and some other thing that stopped working on 99. If everyone can agree that GDC 12 is a baseline that all the libraries should support, then in theory, even if you're still using an older version of the compiler, you might not have all the bug fixed but your library should at least still be targeting the same language version.
Iain said each release of DMD is frozen. Nothing was stopping the community at large from rallying around a specific version and ensuring all libraries are targeting it. Adam said this meeting represents the community at large. If the people on this call are willing to rally around something, then we can try to make it happen. I said that sounds like something that could go under the dlang-community flag. Get a few interested parties to pick a release of DMD, fork it under dlang-community, and backport bug fixes to it.
Walter said there's another aspect to this. As a result of our discussions about IVY and things like that, he'd read Grim Maple's complaints with interest and agreed with much of what he said. So we've been doing a shift in what we're doing with D. One of the changes is we're not going to deprecate things unless we really, really have to. And what that means is that we're going to continue to support things. Our goal is that all libraries are going to work with the new DMD without changes and annoying messages. He'd been steadily issuing PRs to revert several deprecations that had caused people trouble with this. He planned to go through the list of things we've deliberately broken in the past and unbreak them. The idea was that once a library works in D and is debugged, it will stay working in D unless it's something we can't live with in older code.
Walter said that's the plan going forward. He believes it reasonably addresses the complaints like those Grim Maple had and does not require an LTS to work. LTS also has a problem with how to deal with fixing a serious bug in the compiler that does break existing code. That's a conundrum. It's the same conundrum with an LTS and the head version when you have bugs you want to fix but you don't want to break existing code. You're faced with the same decision.
Walter thinks this is a reasonable approach. It means we may not need an LTS version, and we'll resolve the issues that people have been having with their code breaking on every new release of the compiler. We don't want to do that anymore.
I mentioned that Walter had added the -wo switch for this so that when you want to know if a code base is using obsolete features you can turn it on. I also noted that at the quarterly meeting the week before we'd discussed giving that more granular control so that you'll be able to turn warnings on for, say, your code base and not for dependencies. You'll be able to see if you're using any obsolete feature or not without the output cluttered by warnings from dependencies, and it's all opt-in. And of course, we'll still have deprecations.
Walter said the idea is to keep long-term support for features we don't want anymore. If the user wants to upgrade their package and has time to do it on their schedule, and not ours, they can turn on the -wo switch to see a list of all the things they should move forward in time. And they can pick and choose the ones they want to do and ignore the others. That's the plan going forward. He doesn't know if it will work, but he thinks it will. It's worth our efforts to try to make it work.
(As you can read in my July 2023 planning update, we've made a tentative decision on how to evolve the language in the face of this new deprecation policy and the -wo switch.)
Nick
Nick had nothing new for us but did have some comments on the -wo switch. He thought it was great. However, since there's no indication by default if code is using an obsolete feature, he felt it would be great if people could just get in the habit of using the new switch. That could be a sort of cultural thing.
Walter agreed it should be cultural. He had noticed this in GCC. There are some really bad features of C, but GCC doesn't warn about them by default. Users have to turn on the warnings. That seems okay to him and it seems to work for GCC.
I noted that if we're going to make the -wo switch granular, we should also do the same for -d, -de, and -dw. Walter asked if people really care about it being granular. I reminded him that Igor from Ahrefs had brought that up in our quarterly meeting the week before. John noted he had also talked about it in the quarterly. He said it matters a lot because when you have a dependency tree of third-party stuff, you're not going to reach into all of it and change them when they do something old and obsolete and rubbish. You're not going to force them to change. You do want the compiler to tell you about your part of the tree, but you don't want to be spammed with a thousand warnings from a template six library dependencies away from you.
Walter said he'd thought of having a modifier to the switch that says "only give these warnings for files passed on the command line". Basically for the root modules, not for things that are imported. That way you can import other people's libraries and they won't bother you, but you'll get warnings on the stuff you're actively compiling. He thought you might not need a more granular switch than that. John said that's probably workable with build system integration. Walter said it was a very simple idea.
Steve said the only problem he sees is that if you're depending on a library and you want to have warnings enabled for that library, you build the library, then you go into your code and your code uses a template from that library. Does the warning come out of not? Because you didn't pass that module on the command line, you're just importing it to use its template. Walter said that if the warning is the result of a template from a non-root module, you will not get the warning.
Steve said he was just trying to think of situations where you would want to see the warning, but can't. Walter said the compiler already does something similar for deprecations. For example, if a deprecation message is generated for a template that's also deprecated, you won't see the internal deprecation for it. You only get the deprecation on the use of the template.
Steve
Steve reminded us that in the last monthly meeting he had talked about getting compile-time associative array initialization into the compiler. The run-time part of it was already working, he just needed someone to handle the compiler side of it. Since that meeting, he'd had a conversation with Walter and had posted in the forums seeking help. Walter was understandably too busy for it and he was still waiting for a champion to come in and save him. Other than that, he had nothing for us.
(Razvan offered to help with the compiler side. You'll notice in Steve's forum thread that several days after the meeting he had a suggestion for one approach. After he and Dennis discussed it, Dennis put forward a PR for an alternative solution.)
Walter said he'd seen users complain that DMD had stopped working on the Mac. He was aware the same issue had been fixed in LDC. Walter had some questions for Steve since he was under the impression that Steve had been the one to fix it. Steve said he had only reported it and tested it, someone else had fixed it. He said it had something to do with the linker on Mac suddenly being more strict about the way object sections are laid out where it used to be more accepting, or something to that effect.
Walter said it's unacceptable for DMD to not be working on the Mac and asked if Dennis could eyeball it. Dennis said he knew nothing about Mac. Steve said we have a lot of Mac users who might be able to help with testing or building. He offered to give remote access to his old x86 Mac if needed. Walter said he appreciated any help with this.
(The LDC fix was from Johan Engelen.)
Mathias
Mathias had nothing to report.
John
John had nothing to report.
Razvan
The project ideas repository
Razvan said that because we had announced SAOC 2023, he had been looking at the project ideas repository and felt it was too chaotic. We had something like 69 proposals in open issues. Anyone can just propose a project there. That might be fine, but if you're a student or someone looking for a project, you can get a bit confused. You can't know exactly which projects are important and which aren't. Some of them are just descriptions of two sentences. Another thing is that we now have some projects on the DLF's project tracker on GitHub and none of them can be found on this list.
He cited an incident a few years ago when someone picked a project from the list and was accepted for GSoC, then Andrei told him we didn't want to implement it. That was kind of a disaster. So it would be great if we could curate this list. Maybe take some of the issues and put them in files in the repository to indicate projects that we would like to see implemented and that would be suitable for SAOC or GSoC or any other Season of Code. He also thought each project idea should have a mentor associated with it. He wondered if the lack of organization in the list contributed to our not being accepted to GSoC this year.
He said he had tried to curate the list and close some of the issues with proposed projects, but then the people who submitted them came back and wanted to know why they had been closed, and why he didn't think they should be a project. He didn't have a good reason. He couldn't just say that the projects didn't align with our current goals. So that means we kind of need to "approve" some of these projects. For example, on our project tracker, we have a project to implement namespacing in dub. Mathias is in charge of that. Razvan would expect that to be a project here, flagged as "approved" by the DLF.
I said I thought the general idea was a good one. Razvan and I could go through the list, figure out which projects align with our goals, and commit those as files in the repository. That would be the curated list. Those submitted as issues could remain "uncurated" as they are. Regarding mentors, I said our policy for SAOC was that we didn't require applicants to have mentors when they submit. Once their application is approved, there's a window where we can help them find mentors. That's fully in our control, so it doesn't need to change. GSoC is a different story that we'll have to think about for next year.
Razvan said he had gone through the list, submitted some issues for new project ideas, and tagged some other things with labels. He didn't know what a good number was, but 70 project ideas in a single list was probably a bit too much. We need something more focused.
Walter wondered if the uncurated list of projects would be better on the Wiki. Robert thought no one would look there. Razvan thought people would browse whatever link you provide them. I said it's better to have the curated and uncurated lists in one place, in the GH repository. Then the README can explain the difference. Point them to that and they can decide if they want to pick a preapproved project that aligns with our goals or something else. Mathias noted that we're moving the issues from Bugzilla to GH, so why would we move some issues from GH to the Wiki?
(Razvan and I haven't yet gone through the project ideas in the issues list, though I have updated the readme with an initial draft. I hope to have everything sorted shortly after publishing this summary. We're still going to try to keep the ideas in the issues list properly labeled, and I intend to go through them to ensure they have enough information. I also intend to update the new readme to further clarify the distinction between the two lists of project ideas.)
BetterC linker errors
Razvan next brought up a topic we've discussed in past meetings.
There are some issues in the bug tracker that are related to linker errors when using BetterC. What typically happens is that when you instantiate a runtime hook, or maybe import something from DRuntime, if you instantiate the template with the same arguments once from a speculative context from the runtime and once from your BetterC code, the template might not be emitted. Then you get the linker error.
The workaround for this is to compile with -allinst. Razvan said he had made a pull request to fix this such that compiling with -betterc now implies -allinst. He expected that was going to cause a compilation slowdown for some projects. The PR was there and Martin had said that it's no problem to go down that route, but Razvan wanted to know if anyone in the meeting thought it wasn't a good solution.
Walter asked why we can't just tell people to use -allinst with -betterc. Razvan said that even then people wouldn't know about it, so they'd end with the same uninformative linker errors. Walter conceded the point but said he was concerned that if we combine the two, then one day in the future people are going to want -betterc without -allinst for some reason or another.
Steve suggested we could have a version of -allinst that allows you to specify that it should only instantiate templates from specific modules. Like a root module, or anything that comes out of core. Walter said that's a possibility.
Walter suggested another possibility would be to not have DRuntime instantiate its own templates. Have it use different templates. Then the compiler would think that they're not being used by DRuntime. It should only be a handful of templates. Robert thought that would be unworkable. Steve said it's not just the runtime. It could happen with any module, even those you don't directly import. Like, a module isn't part of a public API, but in the private internal API, it happens to instantiate a template. It's difficult to answer those questions of where an instantiation is happening and why the compiler decided not to emit it.
Walter said Razvan should go ahead with his solution. He would like to have a better solution for this, but this was the only one we had at the moment.
Steve said that to be fair, BetterC is the switch specifying not to link the runtime. It could also take the stance to say that it's not going to instantiate templates from there since it isn't linking with it. Dennis noted that BetterC users want more and more things to work with BetterC. He can tell them it's supposed to be for integrating new code with existing C projects and some niche micro architecture things, but they still just want array comparisons to work in BetterC.
This led to a brief side discussion about array comparisons in BetterC, including an issue Steve had encountered with string comparisons when someone tried to use his Raylib bindings with BetterC. Walter thought he had fixed string comparisons, so they should be working now.
Razvan brought us back on track by suggesting an alternative: in BetterC the compiler just assumes -allinst only for the runtime hooks. That might work, but it seemed a bit hacky. Walter joked that -allinst is also a bit hacky itself. Then he said Razvan's initial idea was on the right track and Razvan should proceed with his PR.
Dennis
Safety errors and -wo
Dennis started by noting that Walter had been moving safety errors behind the -wo switch. He found that a bit iffy because safety errors aren't obsolete. Telling users that if they want proper memory safety they have to enable the check for obsolete warnings sounds messy. Dennis didn't agree with that approach but didn't have a counterproposal.
(Two PRs to which Dennis specifically linked:
)
Dennis said he gets that the current flood of deprecations by default is annoying, but if we ever want to get to DIP 1000 by default, it needs to happen. If we don't, then why do we still have DIP 1000 and memory safety?
Walter said that in that first link, there's a BuildKite error from dlang-tour/core, and it's a blizzard of deprecation messages about scope. You don't have to turn on -preview=dip1000. They happen by default. The problem is that people have existing, working code that they added scope to in good faith and now we've broken all their code. Dennis said it's not broken, it's just a deprecation message. Walter said that the dlang-tour thing had been broken for several weeks and hadn't been fixed. That's exactly what -wo is trying to address is that the libraries people use break and nobody wants to fix the library.
Dennis said it wasn't broken because of that. That was just a warning. It was broken because of a hyperlink that didn't work. Walter said all he saw were all kinds of messages about assigning a scope parameter to a non-scope parameter. Dennis said that didn't break the build. What broke the build was a PR that added some markdown links which for some reason failed to resolve. That's why it's failing.
Walter said he understood. The point remains that we still have this problem of a blizzard of deprecation messages where we're saying that in the future this code won't compile at all. Dennis said that's the truth and asked if we didn't want to move forward with DIP 1000. Walter replied that we do want to move forward with DIP 1000, but we also want to compile older code. He emphasized that he understood where Dennis was coming from and would have agreed with him completely two or three months ago. But he thinks now that we're just breaking the existing code of people using scope even when it has no bugs. Yes, he wants to move to DIP 1000 by default, but he doesn't want to break existing code.
So that's the purpose of -wo. The compiler will accept code that isn't acceptable in modern D so you can still use that old code. Nobody wants to pick up an old library and see several screens full of deprecation messages or outright errors on a library that used to work and is free of bugs. It's just that the compiler wants to enforce a stricter standard on things. Walter feels we need to relax those standards.
Steve said that part of the problem with the blizzard of deprecation messages is that a lot of them are trivial. Like, this template is inferred as @safe now, but it will be inferred as @system once DIP 1000 is enabled by default. So you might not really be calling it from safe code. So even though it's going to be inferred as @system later, that isn't going to affect the compilation of your project.
Walter talked a little about the implementation details of the safety inference, then said that people use scope and expect it to work. And it has worked. It's just that with the modern version of D and the direction in which we want to go, that's a problem. But to support this older code, we need to have it behave the same way as it always did by default so that it doesn't interfere with unsafety when they use these constructs. That's the whole point---to stop breaking user code.
John said there was something about D not being able to build, or the way people write D not being able to create, encapsulated code. Consider a C library that you want to continue using in the future. C libraries tend to expose a relatively limited interface but then may do all kinds of crazy stuff inside it. But that interface, you can trust it's been debugged. So getting new warning flags turned on for it is annoying. But in D, we have templates going one way and mixins going the other way, and introspection all across the board. It's harder to get behind the idea that people can build a library, have it "debugged", and users can trust it for the future. Though he's supportive of the -wo switch, he thinks it slightly weakens the argument for it. For example, if your dependencies aren't following the rules for DIP 1000, that means you're probably not following the rules. It's very easy for that to be the case if you pass some type to a template, and it's passed to another template, and another, or something.
Walter said he understood John's point. Walter sees -wo as being for people who have a higher standard for the code they're writing. If you use it, the compiler is going to tell you everything wrong with the libraries you're importing and you can decide what to do about it. Do you want to use this library from 10 years ago even though the compiler can't guarantee it's memory-safe? Let the user make the choice. John conceded that may be the best we can do.
Walter noted C compilers will implicitly declare a function for you when you don't. That's just terrible because it defaults certain parameters and the return value. All of that becomes implicit, even though it could just be a typo in your code. The compiler will still compile that without complaint because people have a lot of old C code that they don't want to fix, but they do want it to compile and work the way it always has. We need that for D.
Walter then talked about how someone had told him that despite all the evolution Java's gone through over the years, you can still compile Java code from the 90s. It will still compile and run as it did in the 90s. This is an extremely important characteristic and one that we've been too dismissive of. He said that the forum thread Grim Maple spawned indicates we made the wrong decision on that.
I said I was still trying to understand what happens when DIP 1000 becomes the default. I get the other deprecations he was reverting and putting behind -wo, because they were removals. The scope stuff wasn't a removal. It was a transitional thing to warn people that the behavior's going to change when DIP 1000 goes default. When it does go default, that's suddenly an error and all that old code is going to break anyway. Were we going to put DIP 1000 behind -wo?
Walter said he didn't see any other way. It's going to wind up on -wo. I said that then it's not the default. John said this is sounding very much like language editions, and I agreed. Walter said people who want safety are going to enable -wo and people who don't won't.
Dennis said we currently have a way with -preview and -revert. He felt like a lot of what we're doing now is just changing the color of messages and changing whether they're the default. If we do this back and forth, it's just going to become a mess. First, you need -preview=dip1000, then you need -wo, and then what happens later when people want memory safety by default? I agreed and said I didn't see how we get DIP 1000 by default without a hard boundary. As John said, we'd need editions or something because that's just earth-shattering. It's a huge change.
John asked why we're positing that warnings about obsolete features should be opt-in to turn them on rather than opt-out to shut the compiler up. I said it's because we'd received so many complaints about the current status quo with the deprecation messages which, right now, you have to opt out of.
John asked if we've considered whether that has to do with the fact that they're deprecation messages, so the compiler's telling you to "beware, you have to change this otherwise your code will get broken" as opposed to "hey, here's a bunch of ways you're wrong, you can ignore them if you like". Because the thing about a deprecation message is that you know you shouldn't ignore it. Not because you know better, but because it's going to break somewhere down the line.
I noted that Martin had been complaining about the scope deprecation thing on the Symmetry code base for the last few meetings because there were a bunch of places where it was coming up in dependencies outside of Symmetry's code. And I understood that to be one of the reasons that are preventing them from upgrading to a newer compiler version. Dennis said that could be solved with the filter patterns to the deprecation and warning switches. John said that's enough in some cases.
Walter said he remembered that Sociomantic spent something like 10 years upgrading their code from D1. He never understood exactly what problem they were having with it, but he felt like we had kind of convinced them to hate us because we just weren't compiling their old code that they'd invested so much effort into. And he didn't want that to happen with Symmetry or our other customers. And if that means that they can't upgrade to the latest compiler, then they need a way to not be forced into it. Dennis said that's what -preview and -revert are for.
I reminded everyone that we're not getting rid of deprecations completely. I thought the scope thing was a perfect example of one that should stay. As long as we have filters for the deprecation switches like -d, then users can leave deprecations on for their own code and turn them off for specific packages.
Mathias said that Sociomantic didn't stay on D1 for the longest time because of a blizzard of deprecations, but because there was no clear upgrade path from D1 to D2. It was just a hard break. The bulk of the work they had to do was to build a transition path for themselves. They did port Tango to D2 at some point, so they had to split Tango from its runtime. They had to build ways to make the code compile in both D1 and D2.
Walter said he didn't want anything like that to happen again. Mathias said he didn't either, but a blanket ban on deprecations, which was what this was amounting to, wouldn't help either way. He said people want their code to evolve in the right way. Maybe we've taken an attitude that's too cavalier about going in one direction. The scope deprecation was certainly intrusive, but many of the other deprecations were not. He had suggested in the past that we cluster deprecations, for example only one release with deprecations every two years. But freezing the language is just dying. Even Rust changes the language once a year.
Walter said he was told Rust will still compile old code. I said that my understanding was that Rust has "epochs", the idea being that there are clear boundaries between sets of new features where upgrading is necessary, but old code still compiles (you can read the RFC for it, which I had not seen before the meeting). I said we need to define and document a clear path for how we handle deprecations, how we handle obsolete features, and how we handle huge breaking transitions like DIP 1000. If we're just sitting and discussing it in meetings and not defining a path that everyone can follow, then we're never going to get anywhere.
Mathias said he thinks it's already quite clear. Deprecations last for ten releases. That's been the case for a while. Some deprecations have lasted longer. The body deprecation, for example, was twenty releases because it was quite impactful. But we never make a hard break, or at least we try very hard to avoid it. That's why when we decided that we needed to move forward with DIP 1000, Dennis did the impactful work of turning the future errors you'll see when DIP 1000 is on by default into deprecation messages now. Because otherwise, there was no way to enable DIP 1000 by default. If we're not allowing that anymore, then we no longer have a way to turn on preview switches by default.
I said that the deprecation of the scope behavior was a transitional thing that was kind of decided on the fly. We didn't sit down and plan everything out. I think we need to lay out a policy for that kind of thing so that we can see what it is we're doing.
Razvan said he thought the recent effort to undeprecate things was not the right direction. Yes, there'd been some pushback about emitting too many deprecation messages, but no one suggested we never deprecate anything ever again. So he didn't understand why we're doing this, because he saw the deprecation process as correct. The major problem was that we'd deprecated too many things, but the process itself was working. Maybe we should just have a hard limit on how many deprecations we make in a given period. Because it was going to be a big problem down the road if we just froze the language.
Walter said those were good points, but he emphasized that he didn't intend to never do deprecations. What he wanted to do was to look at each one on a case-by-case basis and decide if we really need to deprecate it. For example, the rationale for eliminating comma expressions was so that we could have a reasonable tuple syntax. We deprecated it and that's okay. But there are other things like the body keyword, which we deprecated in favor of do. But it turns out we can just leave it in the language as a contextual keyword and it works fine. We can support it forever, even if it's not an official part of the language. And then -wo can tell you, hey, why don't you change the body in your code to do? Or the deprecation of empty statements with a semi-colon. There's not a good point to break people's code over that. It's not a problem leaving it in, so he had a PR to re-enable it. The only difficulty was with DIP 1000 things.
I said I was totally with him on reverting all of that, but I thought it was a mistake to revert the scope thing. Walter said we should also consider that DIP 1000 isn't perfect yet. It still has bugs. Do we really want to start deprecating things before we have all the bugs out of it and can confidently say that you should be using DIP 1000 on all your code? That's another aspect. Maybe we can revisit this when we have DIP 1000 in a much more perfect state. In the meantime, he wanted to proceed with those two PRs putting some of the scope things behind -wo. Like the scope constructor thing. He'd known that was going to be disruptive when he realized we had to do it, so he had preemptively added scope to all of the constructors in DMD. But turning that on for users is pretty disruptive for them.
Dennis said he understood. He didn't mind if we say we've been a bit preemptive, let's turn off the deprecations for now and turn them back on when it's in better shape. His problem is with putting them behind -wo. It's not going to help but just creates confusion when the state is shuffling between versions. And it's going to be intractable if you get a warning and deprecation or error depending on which DMD version you have and which flags you use. So he'd rather see the deprecation disabled for now instead of put behind -wo, and maybe enable it when it's in better shape. We're just going to get complaints from users about the mess of switches.
Steve said he had been playing around with the blizzard of scope-related deprecation messages by building vibe.d. He was seeing messages saying this function can't be called safe because it calls this other function somewhere deep within Phobos. That shouldn't happen. We shouldn't have enabled that until Phobos supported it. Walter agreed. He said Phobos should work perfectly with DIP 1000. That shouldn't even be up for debate.
I noted that we're all in agreement on that. So the question before us was whether we just temporarily disable the scope deprecation messages as Dennis suggested, or put them behind -wo as Walter wanted to do. Steven agreed they should be disabled. Walter said putting them behind -wo is a good way to disable them. Dennis disagreed, saying that didn't make sense because it's not an obsolete feature. Walter said that Dennis was semantically correct, but pragmatically he thought it would be fine. Dennis said users had complained in the past about switches doing other wacky things.
At this point, Iain suggested we park this conversation for now and come back to it in a planning session. We all agreed to do that, and I put it on the agenda for our planning session the following week.
(We did discuss this in our planning session on July 21st. You can see the decisions that came out of that session and our subsequent session on the 28th in my July 2023 planning update.)
void initialing Booleans
Dennis wasn't yet finished. The last item he had for us was a PR he had submitted that marks as @system the void initialization of a bool, or anything that contains a Boolean, under the system variables preview. The compiler likes to avoid bounds checks if you index with a bool because it knows it can only be zero or one, but when the bool is void initialized, it might be something bigger than that and can corrupt memory. (The PR is attempting to fix an issue brought up in our Gripes & Wishes campaign).
He said there were a few different opinions on what should happen here. One is for every void initialization to be @system, but that's a bigger breaking change that he doesn't think is going to happen. It might be helpful to consider bool a type that has unsafe bit patterns. Walter said he would have to think about it, and thanked Dennis for bringing it up.
Iain said that on the GDC side, up until recently all Boolean reads were bitmasked by 1. He'd pulled back on that and now it's only done if it's a Boolean read of a field that's somewhere inside a union. Dennis agreed that's another option that DMD does in certain cases, but it's less performant. If we want a performant and safe bool, it's better to handle the void initialization case. Iain said the performance aspect was why he'd pulled back on it.
Walter repeated that he would have to think about it. He didn't want to make a snap decision because he didn't know what the obvious solution was.
Iain
Iain said that he'd released GDC 10.5 a few weeks back. It shipped with five regression fixes from the previous release and would be the last version of the 10 series. GDC 10 maps to DMD 2.076.
He was also preparing to push out GDC 13.2. GDC 13 maps to DMD 2.103. He had backported around ten regression fixes for it so far.
GDC 14, the current development version, was still tracking the upstream DMD mainline. There were no blockers there and everything was going fine merging from DMD master down to GDC.
As for DMD, he had pushed out 2.104.1 on July 1st, but he'd noticed that the downloads page hadn't yet been updated. He asked if someone with merge rights to the dlang.org repo could handle it because he wasn't able to at the time. I checked the PR and found it had already been merged. Iain said he would have to get in touch with Jan Knepper or Vladimir Panteleev. Jan, who maintains our digitalmars.com/dlang.org server, kindly migrated us to a new box recently. If the download page wasn't updating, then Iain suspected the website probably hadn't updated since the migration. (The issue has since been resolved.)
He wasn't able to get out the beta release for 2.105 on July 1st, partly because of time constraints on his side and partly because after the server migration some permissions on the FTP directory were missing. He hadn't been able to finish running the release scripts in one sitting, but that had now been sorted and uploaded.
He said that now he should probably cut 2.105. He would first cut a point release of 2.104 with all the latest regression fixes that had gone into the stable branch over the previous two weeks, then we could have a short beta for 2.105.
He said he was aware of discussions of how rapid our releases were and that people wanted to slow down, but he didn't think making a decision based on a forum post would be appropriate, and this meeting wasn't the right forum to decide whether we should change our release schedule.
Ali
Ali had nothing to report.
Walter
Walter said we had already covered most of what he'd wanted to talk about. Aside from that, he was focused on bug fixes, going through the deprecation list, and looking into adding support for the ENDBR instructions to the DMD backend (as requested in a forum post from Brian Callahan so that the compiler could continue to work on OpenBSD). That was all he had for us.
I asked Walter if he'd made any progress on DLL support and documentation. At our June monthly meeting, he said he was going to investigate the current state of DLL support in the compiler, write an article documenting what he found, and try to complete whatever was lacking. Walter said he had a DLL-related PR that had stalled, so he'd moved on to other things. However, he had posted an article to the website that he intended to expand once more progress could be made on the implementation. I suggested we put that on the agenda for a future planning session and he agreed. (We had two subsequent planning sessions where we had more pressing issues to resolve. As I write this, I'm not sure if we'll have another planning session before DConf, though I expect we won't. Either way, I'm planning to add this topic to the agenda for a post-DConf session.)
The next meeting
Our next monthly meeting is scheduled for August 11, 2023, at 15:00 UTC.
As a reminder, anyone who has an issue to discuss with us is welcome to join us for any of our monthly meetings. Just let me know and I'll see about getting you into one of them.
