D Language Foundation June 2026 Monthly Meeting Summary

[Mike Parker]

The D Language Foundation's June 2026 monthly meeting took place 
on Friday the 12th and lasted about two hours and twenty minutes.

## The Attendees

The following people attended:

* Walter Bright
* Rikki Cattermole
* Jonathan M. Davis
* Martin Kinkelin
* Dennis Korpel
* Mike Parker
* Robert Schadek
* Steven Schveighoffer
* Adam Wilson
* Nicholas Wilson

## The Summary

Earlier this year, we decided that the first edition would be 
focused on turning a set of deprecated features into errors as a 
way to kick the tires on the editions implementation. After a 
brief discussion [in our April monthly 
meeting](https://forum.dlang.org/post/gfljhyttpprhzoigmqet@forum.dlang.org), and in the absence of an up-to-date list of deprecations, Walter generated a list from the compiler source via `grep`.

We started discussing the deprecations in a May planning session, 
but given that the list was hard to follow and that no one had 
fully reviewed it, Robert created a new list that we all reviewed 
before the June monthly meeting.

Our sole agenda item was to go through each deprecation on the 
list to determine which of them should become errors in the first 
edition. As we went along, Robert consulted the source code for 
each deprecation so we could be certain what it was doing and 
where it was in the deprecation cycle.

We took a somewhat conservative approach. If the deprecation was 
less than two years old (our standard deprecation period), or if 
we were unable to come to agreement about the fate of a 
deprecation in a few minutes, then it went on the 'punt' list. 
Otherwise, it went on the 'Safe to be errors' list.

### The punt list

__complex and imaginary types__

We had agreed in [the May monthly 
meeting](https://forum.dlang.org/post/joidnmeclfehyuygfwjd@forum.dlang.org) that complex and imaginary built-in types should be undeprecated and their use discouraged, so that meant they went onto the punt list for the purposes of this meeting, i.e., they aren't going to become errors. We can discuss at a later date when to undeprecate them.

__const variable initialization in static this__

Dennis said the original error had assumed only immutable global 
variables were put into global memory, but const variables were 
also put there. The error should be consistent with how immutable 
globals were put into the global data section. It was made a 
deprecation because of breakage.

Jonathan and Steven objected that const variables shouldn't be 
put into non-TLS memory. Walter agreed with Dennis, that it 
should be put into shared memory but not typed as shared. This 
sparked a discussion that reached no consensus, so we added it to 
the punt list.

__immutable/shared/const/postblits__

We punted on this because there are still issues with copy 
constructors. It would be premature to force users away from 
postblits until copy constructors were bug-free. However, we did 
agree that another postblit-related deprecation, where 
implicitly-generated postblits hide copy constructors, was safe 
to become an error in the first edition.

__noboundscheck__

There was disagreement over whether this should become an error 
or just a no-op. Generally, we agreed that switches that were no 
longer valid, like `-dip1025`, should be no-ops, but the nature 
of this switch is something you probably wouldn't want to make 
invisible. In the absence of agreement, we punted.

__auto and ref must be adjacent__

Still in the deprecation period.

__auto ref return must have auto and ref adjacent__

Ditto.

__typesafe variadic parameters with class type__

Ditto.

__overriding a deprecated method__

This was another case where we failed to find a consensus. What 
actually is the best solution when a derived class overrides a 
deprecated base-class method? Requiring the override to be 
deprecated may not be desirable, but simply removing `override` 
isn't possible while the base-class method still exists. We 
punted.

__implicitly overriding @future base class method__

Walter had implemented `@future` at the request of Sociomantic. 
None of us were aware of any code using it. The consensus was 
that we should just ignore this deprecation until we decide what 
to do about `@future`.

__overriding extern(C++) with const-qualified function__

Still in the deprecation period.

__ at safe function calling unsafe code (DIP 1000 transition)__

It was unclear what the state of this is. Dennis was sure it was 
on a dead code path. Jonathan believed this was something that 
needed to be made an error in some fashion, but we didn't need to 
decide it now.

__non-zero compile-time return from opApply__

Still in the deprecation period.

__return expression has no effect__

It wasn't clear what this was actually referring to, so we punted.

__truncating conversion in compound assignment__

Still in the deprecation period.

__variable shadowing in foreach__

This appeared to be something related to `opApply`. We punted to 
investigate it later.

__C preprocessor directive in token string__

Walter didn't think this needed to be deprecated and no one felt 
strongly that it should be, so we punted.

### The special cases

There were two traits that had been renamed and the old names 
deprecated: `isVirtualFunction` and `getVirtualFunctions` in 
favor of `isVirtualMethod` and `getVirtualMethods` respectively. 
[The deprecation had happened in 
2.103](https://dlang.org/changelog/2.103.0.html#dmd.get-is-virtual-function), but Robert discovered that the `isVirtualMethod` and `getVirtualMethods` implementations had been added as bug fixes for the existing implementations in 2.058. [That was released in 2012](https://dlang.org/changelog/2.058.html).

Given the age of the fixes, we decided to replace the buggy 
implementations of `isVirtualFunction` and `getVirtualFunctions` 
with the corrected implementations, and that `isVirtualMethod` 
and `getVirtualMethods` should alias those.

### Deprecations to become errors in the first edition

Here's the list:

- Package Not Accessible Without Static Import
- Initializing Field With Itself
- Implicitly-Generated Postblit Hides Copy Constructor
- Function With enum Storage Class
- Storage Class Has No Effect in Type Aliases
- in Parameters With Non-D Linkage
- Function Template Marked override
- Function Template Marked abstract
- @disable on Overriding Function
- deprecated on Overriding Function
- Dual-Context Function
- Function Overload Conflict With Different Attributes
- Bare catch Without Exception Type
- return in scope(failure) Body
- asm Statement Marked @safe
- Throwing Qualified Type
- Catching Non-Mutable/Non-Const Qualified Type
- For-Loop Increment Has No Effect
- Foreach Loop Index Implicit size_t Conversion
- Casting Delegate to Pointer
- __traits(getAttributes) on Overloaded Function
- assert With String Literal Condition
- static assert With String Literal Condition
- Arrow Syntax Returning a Delegate
- Identity Comparison of Static Arrays
- Type Used as Value
- Slice of Static Array Temporary Assigned to Longer-Lived 
Variable
- Non-D Linkage Static Constructor/Destructor
- Invalid Format Specifier
- More Format Specifiers Than Arguments
- Argument Type Mismatch

## Conclusion

Our next meeting was a quarterly meeting on July 3rd. Our next 
monthly meeting took place on July 10th.

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