• Mike Parker (789/789) Aug 11 2023 The D Language Foundation's monthly meeting for July 2023 took
• claptrap (6/17) Aug 14 2023 Maybe if the compiler detects that depreciated features are being
• Dom DiSc (2/7) Aug 14 2023 Jup, that's a very good idea.
• jmh530 (3/13) Aug 14 2023 Yup. It would be nice if the message would only appear if
• Ogi (5/7) Aug 14 2023 Well, given that D compiler is also a unittesting tool, codecov
• Brian Callahan (3/11) Aug 14 2023 And a big thank you to Walter and the LDC team for moving quickly
• harakim (66/71) Aug 15 2023 Addressing deprecations, I think deprecation messages are good if
• Dukc (19/38) Aug 20 2023 Would not be recommended anyway. It'd mean any union with `bool`
• Martin Tschierschke (6/11) Aug 22 2023 I am very happy, that the basic idea behind an LTS Version was

Mike Parker <aldacron gmail.com> writes:

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 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




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.)


__Standalone static constructors__

(First, some background. At one point during [the June monthly 
meeting](https://forum.dlang.org/thread/jekkkcemzjaxcybgvovn forum.dlang.org),
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](https://forum.dlang.org/post/vccxtwaaxqxxjojgxbhj forum.dlang.org).)

__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](https://github.com/dlang-community). 
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](https://forum.dlang.org/thread/ijbtgciijtxmlfzganpd forum.dlang.org).
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](https://forum.dlang.org/post/vccxtwaaxqxxjojgxbhj forum.dlang.org),
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 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 reminded us that in the last monthly meeting he [had talked 
about getting compile-time associative array initialization into 
the 
compiler](https://forum.dlang.org/thread/jekkkcemzjaxcybgvovn forum.dlang.org).
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](https://forum.dlang.org/thread/u7kn6o$97u$1 digitalmars.com). 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](https://github.com/dlang/dmd/pull/15468).)

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](https://github.com/dlang/dmd/pull/15468).)


Mathias had nothing to report.


John had nothing to report.



__The project ideas repository__

Razvan said that because we had announced SAOC 2023, he had been 
looking at [the project ideas 
repository](https://github.com/dlang/project-ideas/pulls?q=is%3Apr+is%3Aopen+
ort%3Aupdated-desc) 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](https://github.com/orgs/dlang/projects?query=is%3Aopen) 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](https://github.com/dlang/dmd/pull/15404) 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.



__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:

* https://github.com/dlang/dmd/pull/15411
* https://github.com/dlang/dmd/pull/15391

)

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](https://github.com/dlang-tour/english/pull/364/files) 
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](https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md), 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](https://forum.dlang.org/post/vccxtwaaxqxxjojgxbhj forum.dlang.org).)

__void initialing Booleans__

Dennis wasn't yet finished. The last item he had for us was [a PR 
he had submitted](https://github.com/dlang/dmd/pull/15362) 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](https://issues.dlang.org/show_bug.cgi?id=20148) brought up 
in [our Gripes & Wishes 
campaign](https://github.com/dlang/vision-document/blob/main/gripes-wishes-feedback.md)).

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 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 had nothing to report.


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](https://github.com/dlang/dmd/pull/15415) to the DMD 
backend (as requested [in a forum post from Brian 
Callahan](https://forum.dlang.org/thread/ertsopsczhtgstoqusct forum.dlang.org)
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](https://github.com/dlang/dmd/pull/15298), so he'd 
moved on to other things. However, he [had posted an article to 
the website](https://dlang.org/articles/dll-windows.html) 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.)


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.

claptrap <clap trap.com> writes:

On Friday, 11 August 2023 at 13:37:57 UTC, Mike Parker wrote:
 The D Language Foundation's monthly meeting for July 2023 took


 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.

Maybe if the compiler detects that depreciated features are being 
used it could add a line to the output...

"To check for usage of depreciated features uses the "-wo" swicth"

A simple 1 line "friendly reminder" instead of pages of warnings, 
surely people could live with that?

Dom DiSc <dominikus scherkl.de> writes:

On Monday, 14 August 2023 at 08:42:17 UTC, claptrap wrote:
 Maybe if the compiler detects that deprecated features are 
 being used it could add a line to the output...

 "To check for usage of deprecated features use the '-wo' switch"

 A simple 1 line "friendly reminder" instead of pages of 
 warnings, surely people could live with that?

Jup, that's a very good idea.

jmh530 <john.michael.hall gmail.com> writes:

On Monday, 14 August 2023 at 12:20:50 UTC, Dom DiSc wrote:
 On Monday, 14 August 2023 at 08:42:17 UTC, claptrap wrote:
 Maybe if the compiler detects that deprecated features are 
 being used it could add a line to the output...

 "To check for usage of deprecated features use the '-wo' 
 switch"

 A simple 1 line "friendly reminder" instead of pages of 
 warnings, surely people could live with that?

 Jup, that's a very good idea.

Yup. It would be nice if the message would only appear if 
deprecated features are actually being used.

Ogi <ogion.art gmail.com> writes:

On Monday, 14 August 2023 at 08:42:17 UTC, claptrap wrote:
 A simple 1 line "friendly reminder" instead of pages of 
 warnings, surely people could live with that?

Well, given that D compiler is also a unittesting tool, codecov 
analyzer, documentation generator, profiler, static analyzer, 
build system, and nowadays also a C compiler, it could also be a 
linter.

Brian Callahan <bcallah openbsd.org> writes:

On Friday, 11 August 2023 at 13:37:57 UTC, Mike Parker wrote:

 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](https://github.com/dlang/dmd/pull/15415) to the 
 DMD backend (as requested [in a forum post from Brian 
 Callahan](https://forum.dlang.org/thread/ertsopsczhtgstoqusct forum.dlang.org)
so that the compiler could continue to work on OpenBSD). That was all he had
for us.

And a big thank you to Walter and the LDC team for moving quickly 
on this. I've updated all the OpenBSD D packages and all is well.

harakim <harakim gmail.com> writes:

Addressing deprecations, I think deprecation messages are good if 
we are writing code that will break things. I would be surprised 
if anyone wanted these off by default for *new* code they write.

I can see a case for suppressing new deprecations in existing 
code so you don't lose the warns/errors in the noise and so you 
can stop the bleeding by catching deprecations in new code. I 
think it would be interesting to see what the demand is for this. 
If it is enough demand (although I assume still not a lot) I 
think the compiler could actually be changed to do a shoddy job 
of this fairly easily, so long as there is a common function 
called to output a warn/error/deprecation. It would involve 2 
changes to that/those functions: 1. if they want to suppress all 
existing warn|error|deprecation, output to the file instead. 2. 
If they specified a file of suppressions, check that before 
output. I feel like this is a temporary solution to a temporary 
problem that probably doesn't affect a lot of people.

I know this idea will not be popular, but I think deprecations 
should be on by default and this solution as a temporary measure 
would be better than turning off deprecations by default. More 
feedback would be needed to determine what the extent and 
severity of this deprecation message issue is.

The DIP 1000 deprecations are different because they probably 
should not exist based on the discussion. It is no fault of the 
developers and there is nothing reasonable they should do.

On Friday, 11 August 2023 at 13:37:57 UTC, Mike Parker wrote:
 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.

As one of the strongest proponents of backwards compatibility, I 
agree that I would like a sustainable solution to this problem. 
The language has to change over time and breaking changes will 
have to happen. If the solution is not sustainable, it will get 
pushed aside. I think the issue is making the changes affect 
users an acceptable amount, not all or nothing.

I have been thinking off and on why this is such a large problem 
in D for me and has barely even registered as an issue in other 
languages. Four of the reasons that come up each time are:
1. D is still in the hobby phase for me. I put my projects down 
for longer periods of time.
2. I compile all my D dependencies from source. Other than 
Javascript*, I use pre-compiled libraries for projects in all 
other languages.
3. In other languages, there are enough developers that a few 
dozen or hundred well-maintained libraries exist to cover the 
basics.
4. D seems to change here and there where other languages have 
clearly defined roadmaps.

I think 1, 3 and probably 4 will become non-issues if D becomes a 
popular language.

For now, I do wonder why we can't change from building all 
dependencies to just including libraries. If that binary 
interface was stable, the language could change quite a bit and 
maybe it's less of an issue. There is always the option to build 
from source, but if third parties included the compiled library, 
it could keep working long after it stopped compiling.

Another option would be having the library maintainer version 
their library and the compiler compile old versions to link. 
Again, this is based off the assumption that maintaining the 
backwards compatibility of a binary interface is simpler than 
maintaining it in the source.

That wouldn't help with user's immediate projects not compiling, 
but with an upgrade tool or guide, that would be less of an issue 
because you usually know the code. It could also be solved by LTS 
versions or just using an old compiler version. In any case, I 
see any solution to stability as a temporary solution to a 
problem that will not be as big in 5 or 10 years.

*Javascript is an all around pile of garbage and it also rarely 
changes in a significant way. Also, some python libraries I use 
probably come as source.

Dukc <ajieskola gmail.com> writes:

On Friday, 11 August 2023 at 13:37:57 UTC, Mike Parker wrote:
 __void initialing Booleans__

 Dennis wasn't yet finished. The last item he had for us was [a 
 PR he had submitted](https://github.com/dlang/dmd/pull/15362) 
 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](https://issues.dlang.org/show_bug.cgi?id=20148) 
 brought up in [our Gripes & Wishes 
 campaign](https://github.com/dlang/vision-document/blob/main/gripes-wishes-feedback.md)).

 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.

Would not be recommended anyway. It'd mean any union with `bool` 
would have to be ` system`.

 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.

I think `bool` other than 0 or 1 should be allowed, but have 
implementation defined behaviour:

```D
if(*cast(bool) new byte(2)) // implementation defined whether 
executed
// true or false, implementation defined
auto x = *cast(bool) new byte(2) && *cast(bool) new byte(2)
// true or false, implementation defined
auto y = *cast(bool) new byte(2) == *cast(bool) new byte(2)
// same as bool z = void
auto z = *cast(bool) new byte(2) & *cast(bool) new byte(2)
// not implementation defined anymore
z = true;
```

This unfortunately means that dmd has to stop assuming bool bit 
pattern of bool.

Martin Tschierschke <mt smartdolphin.de> writes:

On Friday, 11 August 2023 at 13:37:57 UTC, Mike Parker wrote:
 The D Language Foundation's monthly meeting for July 2023 took 
 place on the 14th.

[...]

 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.

I am very happy, that the basic idea behind an LTS Version was 
discussed, with a/this outcome!

Thank you, to the DLF Team!

Best regards EmTee