D Language Foundation May 2026 Monthly Meeting Summary

[Mike Parker]

The D Language Foundation's May 2026 monthly meeting took place 
on Friday the 8th and lasted about an hour and twenty minutes.

## The Attendees

The following people attended:

* Walter Bright
* Rikki Cattermole
* Jonathan M. Davis
* Timon Gehr
* Martin Kinkelin
* Dennis Korpel
* Átila Neves
* Razvan Nitu
* Mike Parker
* Robert Schadek
* Steven Schveighoffer
* Adam Wilson

## The Summary

### Forum moderation

I opened the meeting with a request that had come in from a forum 
user who uses the mailing list interface. He was annoyed by what 
he called "AI slop" posts and wondered if we could automatically 
moderate all first-time posters.

I explained that the request didn't quite fit the way our forums 
worked. Users didn't need to create an account to post. So in 
practical terms, moderating first-time posters would mean that 
the first post from any new account would be moderated, and all 
posts from users without accounts would be moderated. I didn't 
think that was practical. One alternative would be to require an 
account for posting through the web forum interface, since that 
was where all of the spam was coming from. The spam wasn't coming 
through the newsgroup or the mailing list. I didn't think we were 
at the point where we needed to require accounts, but I wanted us 
to make a decision about the direction we should take if the 
problem got worse.

Walter joked that one wonderful feature of our obsolete 
technology was that nobody knew how to hook up to the NNTP 
interface. I said the problem was the web forum interface. Rikki 
agreed that the spam was definitely coming through DFeed and 
suggested putting all posts from non-user accounts into the 
moderation queue automatically.

My concern with that was the moderation workload. Someone would 
have to go through every post from non-account users and approve 
it. Jonathan said he had thought an account was already required, 
so he had no problem requiring one if it simplified things. From 
his perspective, the amount of spam was already fairly high. He 
said he didn't check the forums frequently enough these days, but 
when he did, it seemed like he almost always had to remove spam. 
Because he used the mailing list, removed spam still showed up 
for him.

That was a useful perspective because I didn't see the same thing 
from the web forum side. A lot of spam either got caught by the 
filter or was removed before I saw it.

Steve asked whether anyone had talked to Vladimir about it. I 
said the user had gone to Vladimir first, and Vladimir had said 
moderation decisions should be brought to the Foundation, which 
was why the user contacted me.

Steve wasn't sure that automatic moderation would have prevented 
the AI-generated posts the user was concerned about. If the issue 
was some of the recent posts, he didn't know whether that would 
have blocked them. He didn't see an ungodly amount of spam coming 
through. Sometimes the spam filter flagged something that might 
be legitimate, and then a moderator had to approve it, but from 
his perspective there wasn't an overwhelming amount.

I said my two main concerns were, first, that requiring accounts 
might upset regular forum users who had been posting without 
accounts for years, and second, that moderating all non-account 
posts could substantially increase the moderation workload. 
Walter said we could add more moderators.

Robert suggested an automatic check for users without accounts, 
something like a simple problem they would have to solve before 
posting. I noted that something like that was already implemented 
for multiple posts in a row. I used to run into it when I was 
posting DIP evaluation results because I had to update multiple 
threads.

Razvan said that didn't necessarily solve the problem because a 
human could still post something completely random. Robert said 
the checks could at least help, and the form could tell users 
that if they were human and wanted to avoid the anti-spam 
protection, they could create an account.

Razvan suggested some sort of AI filter trained on good messages, 
which would put likely spam into the moderation queue. Walter 
found it funny to imagine using AI to detect AI-generated posts. 
Steve asked who would pay for the AI if we were talking about 
LLMs. He also pointed out that CAPTCHAs weren't perfect, since 
even moderators still received CAPTCHA requests.

He suggested a softer version of moderation. A non-logged-in user 
could be moderated at first, but if that user kept posting from 
the same IP address and email address, and the moderators 
repeatedly approved the posts, then the system could start 
letting those posts through automatically. That would avoid 
requiring a login while still putting unknown posters through 
moderation at first.

Rikki said CAPTCHAs had already been bypassed by AI, so they were 
dead on arrival. He suggested a temporary account mechanism 
instead. A user could provide the same name and email they 
already provided when posting, and the system could store that 
information in the browser. If the cookies disappeared, the 
temporary account would effectively be gone. The first post could 
go into moderation, and after that, the user would be fine. Since 
the user was already providing that information, it wouldn't add 
much friction, and it would limit the number of posts that went 
into the queue.

Timon said CAPTCHAs probably slowed down human posters more than 
bots at this point because bots could often get past them 
immediately. Walter suggested checking how fast someone responded 
to a CAPTCHA. If the response came instantly, it was probably 
automated. If the user took a few seconds to read and solve it, 
it was probably a human. Átila said that wasn't quite reliable 
with AI, since AI could take about the same amount of time as a 
smart human. Jonathan and Steve both noted that adding a delay 
would also be easy for an attacker.

Walter said D was a small target, so he wasn't sure it would be 
worth someone's time to tune an attack specifically against us. 
Steve thought that was why the existing D-programming CAPTCHAs 
had been effective. They weren't a standard Internet CAPTCHA that 
bots already knew how to bypass.

The conclusion was that no one objected to implementing some kind 
of additional protection. I said I would talk to Vladimir and see 
what he thought was feasible. Possibilities included whitelisting 
users without accounts based on IP address, storing a cookie, or 
some similar mechanism. Steve liked the cookie idea. Jonathan 
said that whatever protection went in up front, being able to 
whitelist people who had posted successfully would reduce the 
problem. Dennis noted that banning was already IP-address based, 
so a gentle approach could be to moderate the first post from a 
new IP address and then allow future posts unless the IP was 
banned.

Walter said the existing user base should automatically be 
greenlit. I also noted that the user who had raised the issue had 
volunteered to help with moderation if we needed it.

### `pragma(lint)` and linting

Rikki said Manu had asked for a new warning related to unused 
parameters and had submitted a PR that had since been closed. 
Timon had then come up with a set of requirements for how 
something like that should work. Rikki had come up with a pragma 
and someone else [had implemented 
it](https://github.com/dlang/dmd/pull/22840) more or less.

Rikki wanted to discuss the direction we wanted to take. As he 
saw it, there were three options: we could put linting into the 
compiler; we could get Rainer to make Visual D understand 
D-Scanner; or we could tell Manu to switch to an IDE that already 
supported D-Scanner. The direction we chose would determine 
whether the PR lived or died and whether it was worth pursuing.

I said that a linter in the compiler seemed to be the direction 
we had been moving toward anyway when we talked about the 
compiler as a daemon and LSP support. A linter seemed to go hand 
in hand with that. Rikki asked whether that meant we were moving 
forward with a compiler linter. I clarified that I only had the 
impression that this was where we were going. I didn't know 
whether everyone agreed.

Walter said that as he had written in the PR thread, this was a 
significant change to the language and should have a DIP. The 
pull request also needed comments in the code. As it stood, it 
looked like a big blob of code. He thought the general forum 
should be involved. Adding a linter to the language was not 
trivial, and hacking something together with links scattered all 
over the place seemed slapdash to him.

Robert said that on the LSP and compiler-daemon topic, he had 
been one of the people pushing for the daemon, but he would not 
necessarily say that was about linting. He saw the LSP work as 
being more about getting actual compile errors into the editor. 
He agreed with Walter that additional warnings could fragment the 
language. From his perspective, the compiler should be binary; 
either the code compiled or it was an error. He had recently been 
doing Python and TypeScript for work and hated dealing with 
multiple linter passes just to keep the typing somewhat strict. 
He wanted LSP support for actual errors, but he was strongly 
against lint-style warnings.

Steve also disagreed with baking it into the language. He thought 
the direction of DMD-as-a-library was a better path. If we could 
make DMD-as-a-library work, then people could build a linter 
around it. The same applied to LSP. A linter built that way would 
have access to the AST and semantic information, and if users 
wanted to configure it with UDAs or something, that could be 
explored. He didn't think the linter itself needed to be built 
into the compiler.

Walter asked whether Steve thought a UDA would be better than a 
pragma. Steve said linting was about things that were valid in 
the language but frowned upon in some contexts. You might not 
want to see `goto`, for example, even though it was valid. 
Someone might want to turn that kind of check on, but it would 
need to be a way to talk to a linter, not necessarily something 
built into the compiler itself.

Átila agreed with Steve. He didn't like the pragma. If linting 
were in the compiler, he thought we would need a way to opt out 
of checks rather than opt in. Python used comments for that. You 
could ignore a rule for a line because they really meant the code 
to be that way. Mostly, though, he thought we should just have a 
linter that depended on the DMD front end and let people use it 
or not as they saw fit.

Martin also didn't see a reason to complicate or touch the 
language with pragmas or other syntax. On the implementation 
side, he thought the linting logic could live in the front end 
directly rather than as a separate project, but only under 
constraints. It would need to be nicely separated. He didn't want 
extra ugly code scattered across unrelated parts of the codebase. 
A normal compile without linting shouldn't have CPU or memory 
overhead. He would be fine with a little extra tag or pointer on 
AST structures that linter implementations could use, but not 
with normal builds paying a significant cost.

The advantage of having linting in the compiler was that users 
could get unused imports, unused parameters, and similar warnings 
as part of a normal compile. If the goal was only IDE feedback, 
then a separate tool or daemon based on DMD-as-a-library would 
probably be fine.

Timon said he strongly agreed with Robert that a program should 
compile and be fine or not compile. He noted that the specific 
`pragma(lint)` proposal did make that true in a sense. Whether 
the code compiled would depend only on what was written in the 
source file. He wasn't invested in having a linter and was even 
against having an external tool, because that fragmented the 
ecosystem. Some people would run the linter, some wouldn't, and 
some would require linter success before checking code in. If it 
were part of the language, at least it would be clear what was 
going on.

Jonathan said he was generally not a fan of linters because they 
usually meant adding a ton of warnings, and he thought warnings 
were usually a mistake for a language. Things should generally be 
errors or not errors. A linter could be useful for catching 
things that were possibly wrong, but he didn't want any linter 
feature that turned warnings into errors. We already had issues 
with `-w`, which affected what compiled. He thought `-w` should 
stop affecting compilation entirely because it affected 
template-heavy code like `std.algorithm`.

He said that DMD-as-a-library should, in theory, allow people to 
build whatever linter functionality they wanted without adding 
anything to the language. A lot of this stuff could be solved via 
comments and the like. As long as that was available, a tool 
could do whatever without the compiler needing to do any of this. 
And anyway, linters became necessary only in C and C++ land 
because of how insane everything was that was allowed. We didn't 
have anywhere near the same level of issues that would make a 
linter as useful in D.

Adam said that Microsoft rewrote the C# compiler around ten years 
ago to support a plug-in infrastructure where you could add your 
own things. One result was that you could do some really cool 
linting around performance warnings. When he was working with 
Entity Framework, it would warn him that the way he built a call 
would be slow and tell him what to do instead.

He thought they should be warnings and not affect compilation. In 
C#, the linter warnings showed up in the IDE. They would show up 
in compilation, but you had to turn off warnings as errors to 
make it not hateful to work with. Linting was never about errors. 
It was about, here's a different way to do things. Did you not 
think about using `goto`? That kind of thing. So they needed to 
be in the front end. He wasn't saying we needed to go as far as 
writing a whole plugin infrastructure like C#. It was about 
warnings. We weren't going to be treating them as errors because 
they weren't errors.

Walter thought user plugins was interesting. For example, a 
company might want a plugin to enforce their style guide. "Don't 
use the GC", that sort of thing. That may be a perfectly 
reasonable thing, but it would be something users installed and 
turned on, not something wired into the compiler by us. He could 
see value in that, and he could ignore it if he wanted to. His 
experience with C++ linters had given him a strongly negative 
view of linters. He had run multiple commercial linters against 
code and gotten thousands of messages, none of which found actual 
errors, and different linters produced different sets of 
complaints.

If there were a plug-in architecture where individuals and 
companies could add their own linting features, that seemed fine. 
The question remained whether it should be done via a pragma or a 
UDA. He leaned toward a UDA. He also noted that DIP 1000 was, in 
a way, turning on warnings that some people liked and some people 
didn't.

Rikki said a pragma could be a statement, a declaration, and an 
attribute all at once, so it could replace comments. D-Scanner 
and dfmt did replace comments, but comments were thrown away by 
DMD anyway, so he didn't think they could be relied on for this. 
It could just be one pointer stored in the AST nodes, and it 
would be `void*` as far as the backends were concerned. So that 
would help Martin. If a pragma wasn't in a module, that module 
should never be walked by the linter. So it should be freed. It 
should never run.

Walter asked again why this should be a pragma rather than a UDA. 
Rikki said it should be a pragma, because a pragma could be a 
statement in a function body, which meant linting rules could be 
turned on and off in regions. Walter thought that was too 
fine-grained. Jonathan said that was exactly what was needed a 
lot of the time for a linter. You had to mark up your code like 
crazy to ignore this line and that line. It was either going to 
have to be comments or a pragma. A UDA wouldn't work for a lot of 
that, because it wasn't at function level for a lot of that 
stuff. Walter said that maybe it should be.

Timon warned that as soon as we had an official list of things 
that were frowned upon, some people would treat them as errors. 
That had already happened with warnings. Warnings were added, 
then warnings-as-errors were added, then dub enabled 
warnings-as-errors by default, and suddenly warnings became 
errors in practice for many people. He thought the same thing 
would happen with any linter.

He said Manu's original context had been a pull request to warn 
if a function parameter was unused. Timon thought adding more 
warnings was a terrible idea because warnings were fundamentally 
broken. At the same time, he recognized that some people wanted 
aggressive warnings because they had come to rely on them in C++ 
and then found that they got bugs in D code they would not have 
gotten in C++ with their linter settings. From his perspective, 
`pragma(lint)` had looked like the best way to satisfy those 
people without fragmenting the ecosystem too badly.

Robert thought this belonged in D-Scanner. As far as he 
understood, there had already been some work on making D-Scanner 
use the DMD front end as a library, and D-Scanner already had 
some linter steps. Timon said one concern was that D-Scanner 
could complain about code in third-party libraries whose authors 
didn't use D-Scanner and didn't want to annotate their libraries. 
Robert said D-Scanner could simply select which files to scan. If 
you didn't want to scan a third-party library, you could exclude 
it.

Steve went back to plugins. We were already going down the path 
of DMD-as-a-library, which let tools interact with the parser and 
semantic analysis. A plugin system would be a different way of 
doing something similar, so he wasn't sure we wanted plugins. As 
for the implementation, he thought the fact that pragmas could be 
statements was a strong argument against UDAs. The pragma could 
be a no-op in the normal compiler, while a tool using the DMD 
front end could interpret it.

Adam clarified that he wasn't saying we needed a full plugin 
infrastructure like C#. He was only reporting what Microsoft had 
done. He also noted that C# used comments for disabling lints 
because one lint could require you to write a comment explaining 
why you disabled another lint. That documented the reason in the 
source. ReSharper and other tools respected those comments as 
well. He thought it worked well.

Rikki said he was definitely on the side of killing off 
warnings-as-errors, though that should probably be its own agenda 
item. He also said it would be nice to support UDAs on statements.

Rikki said the big practical issue for Manu was that Visual D 
didn't support D-Scanner. It could only call the compiler. 
Talking to Rainer about getting Visual D to support D-Scanner was 
a valid option.

Martin said that implementing linting through plugins would be 
tricky, especially on Windows. Anyone who had played with D 
shared libraries knew that a plugin would need to use the same 
host compiler that had built the compiler itself. If the plugin 
needed to share the GC with the compiler, then the compiler would 
likely need to be built with a shared DRuntime. That was all 
messy.

Regarding pragmas, he saw two uses of any pragma. One was to 
introduce exceptions. In that case, he would say that was 
something for comments. That would give us the option to have the 
linter define its own little language as a comment. For example, 
in Python there was some kind of standard for type annotations 
that was supported by multiple linters. We could also come up 
with some kind of standard interface without touching the 
language itself. We didn't need UDAs or extra pragmas, just 
comments that were uninteresting for anything except the linter.

If the pragma was supposed to be used to enable or disable 
certain linter features on a per-module basis, or even more 
fine-grained on a per-function basis, he thought that was going 
to be very bad. For example, if he were writing a library and 
wanted to make sure none of his library modules had any unused 
imports or unused parameters, he would put that in the dub recipe 
or something. But it definitely wouldn't be in every little 
module, enabling a bunch of lints and disabling the others. In 
that sense, every module would need to define its own set of 
lints, saying it would only compile successfully if there weren't 
any unused inputs or unused parameters.

He thought that should be done on the command line. He saw it 
just like `-W` in GCC to enable or disable specific warnings. 
Very fine-grained stuff. If it was an external tool, he didn't 
care. Then it would be a config file. It could be a config file 
for the compiler, too. He just wouldn't like to see it in the 
module.

Jonathan didn't see how UDAs and statements could possibly work 
for any kind of introspection in general. It might work for some 
compiler stuff, but that wouldn't be at all how UDAs were used in 
general at this point. Usually you were using those and 
introspecting in your code. That wasn't going to work with 
statements.

In terms of other languages, every linter he had seen used 
comments for this stuff, so that would be the normal thing to do. 
If DMD normally stripped comments, then a better solution might 
be a flag to keep comments around for a linter. He thought Ddoc 
already needed to keep comments in some form, so the compiler 
already had some machinery for this. If it was DMD-as-a-library, 
it could just be a setting on the library interface.

Walter said we had experience with line-by-line attributes from 
the early days of `@trusted` lambdas. People would write `@safe` 
code, include `@system` code inside functions, and make it work 
by wrapping statements in `@trusted` lambdas. That got sprinkled 
through code and was ugly. Although the language still allowed 
it, it was considered bad style. He thought it had worked out 
much better to put annotations at the function level rather than 
the statement level. He was skeptical of turning warnings on and 
off statement by statement.

Jonathan said for linters, you kind of had to do it line-by-line 
or statement-by-statement. Yes, it was ugly, and that was part of 
why the whole thing sucked, but generally that was the kind of 
control you needed. He also disagreed with Walter about 
`@trusted` lambdas. They could make clear what was actually being 
trusted. Walter said that if you needed to know what was going 
on, you could make it `@safe` and let the compiler tell you.

I asked whether the discussion had moved the needle. Were we on 
board with putting a linter into the compiler or language, or 
were we saying this should be an external tool using 
DMD-as-a-library?

Walter said the next step should be a DIP. The topic was clearly 
not trivial, and a few comments plus a PR was not the right way 
to handle a major feature. Steve said the first step was to 
propose a way to communicate information for the linter in source 
code, whether through pragmas, comments, or something else. That 
would be needed regardless of whether the linter itself lived in 
the compiler.

Rikki said one of his ideas was a `LintPrograms` struct in 
`core.attribute` that could be passed to the pragma to configure 
the linter. He felt that part was solved. What he wanted to know 
was whether the idea was being killed completely. I said Walter's 
answer seemed to be that it should go into the DIP process. The 
full arguments needed to be collected in one place, not scattered 
across PR comments.

Dennis said the obvious place for this was LSP. LSP already had a 
mechanism to publish diagnostics, and those diagnostics could 
include unused parameter warnings, deprecated code, versioned-out 
code, or whatever else an IDE wanted to show. Jonathan said that 
was fine with him, though he didn't personally care much about 
either LSP or linting.

I wondered whether Visual D could use LSP. Rikki said Visual 
Studio might not understand it. Adam said Visual Studio did 
support LSP, which made sense because LSP came from Microsoft. 
Rikki said that changed things. I suggested he talk to Rainer and 
see whether that was feasible for Visual D.

### Preview switches

Átila wanted to go over old preview switches that weren't turned 
on by default. He thought we should decide whether to turn them 
on by default or consider them failed experiments and remove them.

Jonathan said that in some cases, like `nosharedaccess`, they 
needed to be fixed. Átila said he was working on that one in 
particular, but there were others that weren't such large 
changes, including `fieldwise`, `fiximmutableconv`, 
`rvaluerefparam`, `inclusiveincontracts`, `fixaliasthis`, and 
`systemvariables`.

Rikki said he had been looking at this for the first edition 
before we changed the edition plan. He suggested turning on the 
ones we wanted through editions, except for DIP 1008, which he 
thought was dead because the implementation didn't work properly, 
and DIP 1025. He thought DIP 1008 could be killed sooner if we 
were going to get rid of it outright.

Jonathan said that if we were getting rid of a switch, we could 
do that whenever. All of the enabling should go in editions.

Átila asked if we were saying to turn all the preview switches on 
by default in the next edition except for DIP 1008. I clarified 
that it should be the second edition, since the first edition was 
going to be for deprecations.

Martin said we definitely needed to go through the list one by 
one. For example, he didn't think `rvaluerefparam` was a clear 
100% yes. `fieldwise`, on the other hand, was important, though 
he wasn't sure whether it was already enabled by default. He 
remembered a problem involving unions, where hashing an aggregate 
that contained a union, or hashing the union itself, could 
combine the hashes of all union members even though only one 
member was valid. In their case, one field could be a string or 
array and another could be an integer, and the wrong 
interpretation could lead to treating garbage as an array. His 
point was that we needed to be careful and make sure each preview 
switch actually worked correctly before turning it on.

Átila wondered if we had to wait for an edition. We could turn 
preview switches on by default before an edition, and users could 
still revert them. In an edition, though, they would no longer 
have that choice.

I asked what the point of editions would be if we turned things 
on by default before the edition. Jonathan said the issue was 
breakage. If a library broke because a preview switch was enabled 
by default, and the library was not updated, then existing builds 
would break. Avoiding that was part of why we had designed 
editions the way we had.

Átila said that for the switches we wanted to keep, we could turn 
them on in the edition after the first one. For ones we wanted to 
get rid of, such as DIP 1008, he wanted to know what we should do.

Rikki said DIP 1008 simply didn't work properly. We could keep 
the command-line flag undocumented but make it do nothing, so it 
wouldn't cause an error if someone still had it switched on.

He said DIP 1000 was different. Once the fast DFA escape analysis 
was close to being turned on, we could complete DIP 1000. But 
that was still a while away. He had only been working on it since 
BeerConf, and so far it protected the stack even in `@system` 
functions without false positives.

Átila said it sounded like the first step was to make a thumbs-up 
or thumbs-down decision on each preview switch. Razvan said his 
understanding was that preview switches were experimental 
implementations of experimental features. Editions looked like an 
opportunity either to turn the good ones on by default or delete 
the bad ones, because otherwise they bit-rotted the codebase.

Rikki said someone on Discord had recently asked what would 
happen to preview switches. Rikki had answered that if a preview 
was turned on, the switch would eventually go away, because a 
preview switch was not meant to be a permanent compiler feature 
flag.

Jonathan said he would have to study what the switches did again 
because he didn't use most of them. Átila counted roughly eight 
switches, not including `nosharedaccess`. Jonathan thought 
anything that was clearly fixing an outright bug should be turned 
on as soon as possible, but other behavior-changing switches 
would be debatable.

I said that if we were going to review all the preview switches 
and decide what to do with them, we needed a process. Rikki 
suggested compiling a list of the switches we wanted to consider, 
posting it to the newsgroups, and asking whether people knew of 
any bugs. When he had looked earlier in the year, there were 
issues for some of them, but he didn't think the list was 
complete. That seemed like the first step.

Razvan thought we should look at the switches individually and 
only discuss the controversial ones, since we would probably 
reach a reasonable decision quickly on most of them. I asked 
Átila to organize the process. Martin thought one meeting could 
probably handle it, with some homework for the controversial 
cases. He thought `rvaluerefparam` and maybe `in` contracts were 
likely to require more discussion, while things like 
`systemvariables`, bitfields, and `fieldwise` were no-brainers. 
Some of the others, such as `fixaliasthis`, would need to be 
looked up, but if they were called "fix" something, they probably 
made sense.

Átila said that if we didn't want one of them, there was no point 
fixing issues with it. I said I would schedule a meeting toward 
the end of the month, and Átila should send an email beforehand 
with the list of switches so everyone could review them before 
the meeting.

__UPDATE__: There's a brief summary of the planning session at 
the bottom of this post.

### Power assignment operator

Dennis wanted to get a decision on the power assignment operator 
over with because [the PR had been 
open](https://github.com/dlang/dmd/pull/23023) for two weeks and 
was ready to merge. To him, it looked like an obvious yes.

Walter said he had complained in his reply to the agenda email 
that `a = a * b` behaved differently from `a *= b` with respect 
to value range propagation. Dennis said that wasn't value range 
propagation. The specification explicitly said that `a += b` 
included a cast, and it said that for every operator. The PR 
simply made the power assignment operator consistent with every 
other assignment operator and with the specification.

Walter agreed with that point, but said value range propagation 
had come later. When value range propagation was implemented, the 
operator-assignment cases may simply have been forgotten. He 
asked why we should have value range propagation and then ignore 
it for the operator-assignment cases.

Dennis said it was redundant because the operator-assignment 
cases already downcast by design. Walter still saw it as a value 
range propagation problem and thought that when value range 
propagation was defined or implemented, this case may not have 
been addressed. The question, in his mind, was whether to fix the 
issue by adding value range propagation to operator-assignment 
expressions or by inserting the cast as the PR did. He didn't 
think the answer was obvious. He also said he would rather remove 
the power operators anyway, since they behaved differently from 
other operators and he didn't think they were necessary.

Dennis said that removing the power operators would be a 
long-term, controversial change. In the meantime, making the 
implementation comply with the current specification seemed like 
the right thing to do.

Rikki asked Walter to reply in the email thread with how value 
range propagation was implemented, where he thought it was 
lacking, and how the issue worked. Walter said the problem was 
that `*=` and `*` behaved differently.

Dennis said the power operator wasn't even being called in the 
relevant case. The difference existed because the power 
assignment operator didn't include the cast required by the 
specification. After the PR, it would behave consistently with 
the other operators.

Walter agreed that the power assignment operator didn't currently 
do the cast that the other assignment operators did. His concern 
was that the other assignment operators themselves might be 
wrongly specified or implemented. Dennis said they were 
implemented according to the spec. Walter said he understood 
that, but the spec itself might be wrong. It might be a design 
bug that had been overlooked when value range propagation was 
added.

Dennis said that was a separate issue and shouldn't prevent 
merging the PR. Walter said that if we merged it and changed the 
behavior later, people would be angry. Dennis thought people 
would be angry either way, and the edge case of the power 
assignment operator would not move the needle much. If anything, 
what Walter was suggesting would likely be less popular because 
people already complained that they couldn't add two `short`s and 
assign the result to a `short` without an explicit cast. 
Requiring more casts for assignment operators would go in the 
opposite direction from what people wanted.

Walter said people had liked value range propagation when it was 
first added. Dennis said they liked it compared with not having 
it, but not necessarily compared with simply allowing small 
integer operations to cast back to the original small integer 
type.

Martin looked at the code and agreed with Dennis. He had 
initially been worried that the PR affected all power 
expressions, but it was really just for the power assignment 
operator. He thought the PR was correct. If Walter wanted to 
change the assignment operator behavior generally, we could talk 
about that later. It didn't need to block this PR.

Walter said Martin had a good point. Maybe this was really two 
issues, and we could go ahead with the PR. He asked if anyone 
else objected. Jonathan did not object, partly because he often 
forgot the operator even existed and doubted it affected much 
code. His only concern was whether allowing code that was 
currently disallowed could create breakage later if we changed 
direction. Dennis said any breakage from the power assignment 
operator would be overshadowed by the breakage from changing 
`+=`, `*=`, and the other common assignment operators.

Timon asked whether there were more than zero or one uses of the 
power assignment operator with small integer types in the world. 
Dennis said the bug had been filed some time earlier and had 
recently come up again, so there were at least two occurrences. 
Walter said he still wondered whether we even wanted an 
assignment exponentiation operator. Dennis said it was 
consistent, and the bug had now been raised twice.

Rikki said the power operator was used heavily in areas like data 
science and machine learning, and being able to use it with 
assignment was valuable. Walter said that if everyone wanted to 
proceed with the PR, it was okay with him, even though he would 
never use it. The power operator was of no interest to him.

__UPDATE__: The PR has since been merged.

## Conclusion

Our next monthly meeting took place on June 13th.

If you have anything you'd like to bring to us in a monthly 
meeting, please let me know.

## Planning session update

We held a separate planning session on May 30th. The original 
intent was to review the preview switches, but given that we 
hadn't yet discussed the deprecated features that we wanted to 
convert to errors in the first edition, as we'd agreed [in the 
April monthly 
meeting](https://forum.dlang.org/post/gfljhyttpprhzoigmqet@forum.dlang.org), we decided to do that as well.

We began with the deprecations. We had a list of them that Walter 
had generated with a `grep` over the compiler source after the 
April meeting.

We started with the deprecations of the built-in complex and 
imaginary types. Walter thought it would be good to remove them 
from an implementation perspective, but said doing so was 
impractical because of ImportC and interoperability with C code 
that used imaginary types. After a bit of discussion, we agreed 
to undeprecate complex and imaginary types and discourage their 
use in the documentation.

That was as far as we got. The list Walter had produced was 
difficult to read and had several duplicates, so no one had 
reviewed the entire thing. Robert generated a more readable list 
that associated the deprecation messages with examples and their 
locations in the compiler. We agreed that everyone would review 
that document before the June monthly meeting and that 
deprecations would be our main focus there.

We then reviewed older preview switches with the goal of deciding 
which ones we should enable by default in a future edition, which 
ones we wanted to abandon, and which required further 
consideration.

`dip1008` was the only one we decided should not become a default 
language feature. We agreed that it had substantial problems. It 
can remain available to existing code for the time being, but it 
will not be enabled in a future edition and will ultimately be 
removed.

We decided to defer four switches for further discussion: 
`dip1021`, `fixaliasthis`, `rvaluerefparam`, and `in`. The 
aliasing checks in `dip1021` currently produce false positives 
and may ultimately be better handled by Rikki's new DFA-based 
analysis. `fixaliasthis` raised questions about the future of 
`alias this` itself. `rvaluerefparam` led to an extended 
discussion about C++ interoperability, reference semantics, 
lifetimes, and whether accepting rvalues through ordinary `ref` 
parameters obscures programmer intent. `in` raised questions 
about its `const`, `scope`, and reference semantics.

We approved enabling the following switches in a future edition: 
`fieldwise`, `nosharedaccess`, `inclusiveincontracts`, 
`fiximmutableconv`, and `systemvariables`. `nosharedaccess` still 
requires implementation work before it can be enabled.

Finally, the difficulty we had researching the deprecations and 
some of the preview switches showed that we have a documentation 
problem. Going forward, any PR adding either a deprecation or a 
preview switch should require corresponding documentation on 
dedicated pages for deprecations and preview switches as part of 
the PR.