D Language Foundation July 2023 Monthly Meeting Summary
Mike Parker
aldacron at gmail.com
Fri Aug 11 13:37:57 UTC 2023
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](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
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](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
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](https://github.com/dlang/project-ideas/pulls?q=is%3Apr+is%3Aopen+sort%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.
### 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:
* 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
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](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.)
## 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.
More information about the Digitalmars-d-announce
mailing list