D Language Foundation July 2023 Monthly Meeting Summary

[Mike Parker via Digitalmars-d-announce]

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/jekkkcemzjaxcybgv...@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 

D Language Foundation July 2023 Planning Update

[Mike Parker via Digitalmars-d-announce]

We had two planning sessions in July, one on the 21st and one on 
the 28th.


## Language Editions

### Background
I first reported on our new deprecation policy in [my June 
Planning 
Update](https://forum.dlang.org/post/jmtcppvsweimsojla...@forum.dlang.org). Later, Walter expanded on that in a forum post titled ['Evolving the D Language'](https://forum.dlang.org/post/u87vfb$1b9h$1...@digitalmars.com). The TL;DR:


* we will be much more conservative with deprecations
* Walter is evaluating current deprecations to see if they're 
unnecessary or causing problems and reverting them if so
* we should strive to compile obsolete code by default, i.e., 
features that would otherwise be deprecated, but where possible 
provide a means to opt-in to warnings about its use (in the form 
of the `-wo` switch) rather than taking the opt-out approach of 
deprecation


These changes are rooted in our new vision statement:

To enable the realization of ideas by shifting the way 
programmers think.


Our approach to deprecations was a hindrance to the realization 
of ideas and so was not aligned with our vision. The changes are 
aimed at decreasing breakage and increasing the odds of success 
when someone tries to compile an older D library with a newer D 
compiler, goals that will enable the realization of ideas.


### The decision
In the face of these changes, how can we continue to evolve the 
language? That was the big question we set out to answer in our 
first July planning session.


Átila has mentioned language editions in his talks for [DConf 
Online 2021](https://youtu.be/UqW42_8kn0s?t=961) and [DConf 
'22](https://youtu.be/p1Q2DfYBw-w?t=1848). The topic has also 
come up in recent meetings, most recently in our July monthly 
meeting. After much discussion in the planning session, we agreed 
that editions look like the best way for us to maintain backward 
compatibility while still evolving the language without suffering 
the hard split of a major version change.


[The planning update I published in 
May](https://forum.dlang.org/thread/mqwhekbqqkabdvqpd...@forum.dlang.org) listed the three high-level goals we've set ourselves. One of them is to stabilize the language, so we aren't currently implementing new features. We'll revisit these goals down the road and, at some point, we'll add "evolve the language" to the list. Before that day comes, we need to have our policy on language editions in place.


To that end, Átila volunteered to draft a proposal. When he 
brings it to us, we'll review it and shape it up as needed, then 
ask for community feedback.


One consequence of this is that DIP 1000 will not be enabled by 
default until we can do it in a new edition. The warnings about 
scope parameters, which are errors when DIP 1000 is enabled, will 
remain behind the `-wo` switch. Additionally, Dennis is going to 
see about adding support for filters to `-wo`, `-d`, `-de`, and 
`-dw` so that you can, e.g., enable warnings about obsolete code 
for your codebase and keep it off for dependencies, and shut off 
deprecation messages for dependencies while keeping them on for 
your codebase.


## New Annotation for Static Constructors

### Background
In [our June monthly 
meeting](https://forum.dlang.org/post/jekkkcemzjaxcybgv...@forum.dlang.org), we discussed the problem that DRuntime sometimes aborts execution of static constructors with a "cycle detected" error when modules with static constructors import other modules with static constructors. There should be a way to prevent that when a constructor is truly standalone. The workarounds Walter always suggests are to either put the constructor in its own module with no other imports or to tag it with `pragma(crt_constructor)`. Adam Ruppe and Steven Schveighoffer insisted that isn't always feasible.


Adam came to our July monthly meeting with a proposal: we should 
implement a new annotation that users can apply to a static 
constructor to indicate that it is standalone and should be 
excluded from cycle detection. The result of that discussion was 
that Walter asked Adam and Steve to provide example code showing 
when neither of the suggested workarounds is possible.


In the days after the monthly, I followed up with Adam and Steve. 
They gave me their example code, and I brought it to the first 
July planning session.


Steve's example:
```d
__gshared string[string] dict;

shared static this() {
dict = ["a" : "b"];
}
```

There are two arguments here: this can't be a CRT constructor 
because it depends on DRuntime, and arguing that it should go in 
its own module is a QoL issue---we can make that case for classes 
when you want private-to-the-class rather than 
private-to-the-module because the language is working as 
intended, here it isn't.


Adam's example:
```d
__gshared Object function()[string] factories;

Object build(string s) {
 return factories[s]();
}

mixin template Register() {
 shared static this() {