• Mike Parker (137/139) Aug 11 2023 We had two planning sessions in July, one on the 21st and one on

Mike Parker <aldacron gmail.com> writes:

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




I first reported on our new deprecation policy in [my June 
Planning 
Update](https://forum.dlang.org/post/jmtcppvsweimsojladlj 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.


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/mqwhekbqqkabdvqpdppl 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.




In [our June monthly 
meeting](https://forum.dlang.org/post/jekkkcemzjaxcybgvovn 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() {
                  factories[typeof(this).mangleof] = () {
                          return new typeof(this);
                  };
          }
}
```

This can't be a CRT constructor because of the DRuntime 
dependency, but neither can it go in a standalone module as it's 
intended to be mixed into a class.


The discussion on this topic was not as long as the one above, 
and almost everyone agreed. It was just a matter of bringing 
Walter around. And in the end, he came around.

There are a couple of questions remaining:

* Should it be a pragma or an attribute? Walter favors a pragma 
(and it's consistent with the CRT pragma). Adam favors an 
annotation.
* What should it be called? Walter doesn't want anything negative 
(e.g., `noCycleCheck` or `skipCycleCheck`). `standalone` is a 
possibility.

Although this is a new feature, it fits in with our goal of 
stabilizing the language since it's intended to fix a feature 
that isn't working as intended. So we can implement it as soon as 
the details are sorted.


We discussed two topics in our July 28th session and did not 
reach a concrete decision with either: what to do about 
`std.json` and whether the frontend should act like a linter and, 
e.g., warn about unused imports.

The GC pressure created by `std.json` came up twice in [our July 
quarterly](https://forum.dlang.org/thread/jzlympfqmwckaiuhqo
z forum.dlang.org). Mathis Beer had added a warning about it to the
documentation. I wanted to know if we intended to replace the module and
whether we should note that in the documentation if so. There was a bit of
discussion about whether we could reduce its GC usage without changing its API,
and how we can replace it in Phobos v2, but the only conclusive decision was
that there's nothing to add to the documentation for now.

Dennis had questions about enabling the compiler to do work 
normally done by a linter, like warning about unused imports or 
certain kinds of casts. This took us into a long discussion about 
what is and isn't possible outside of the compiler's semantic 
stages (e.g., what an external tool can do vs. what only the 
compiler can do), and what dmd-as-a-library can and can't do. 
Walter and Martin are generally opposed to adding this sort of 
functionality to the front end (Martin adamantly so, though I 
believe he'd be in favor of plugins). Again, we didn't reach a 
conclusive decision. The plan for now: Razvan will keep moving on 
work for DMD as a library. Once that's complete, we can see what 
it looks like to add this kind of thing to the compiler (maybe 
even as a plugin) and bring it back to Walter then.


With DConf coming and several of us going into travel mode before 
then, it's unlikely we'll have a planning session in August after 
our monthly meeting on the 11th. However, Robert has proposed 
that we get together at DConf and start discussing a ten-year 
plan. So far, we've been tackling immediate problems, both small 
and large, but we haven't begun talking about our long-term 
plans. He feels it's time we do so. The rest of us agreed.

I want to emphasize that this is just a preliminary discussion to 
get the ball rolling, so please don't expect us to have a 10-year 
roadmap ready to go on the other side of DConf. I expect it will 
take us a while to get this sorted out.