DLF September 2023 Planning Update

[Nicholas Wilson]

On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:
> ## Editions
> We had agreed in [the September monthly 
> meeting](https://forum.dlang.org/post/hetwfhikjqwzlvywmyzc@forum.dlang.org) the week before that we need to define what editions will look like before we start deciding which features should go in any given edition.

Good

> My goal with this session was to establish the first point on 
> the timeline: a deadline for the editions proposal. I also 
> thought it would be a good opportunity for all of us to clarify 
> what editions are (there were some different ideas about that) 
> and discuss aspects of the concept we need to consider.
>
> Here are some points that came out of the discussion.
>
> * Editions are essentially feature sets. Each edition can 
> add/remove/deprecate features.
> * Editions are entirely opt-in and only affect the source you 
> explicitly apply them to, i.e., they are not transitive to 
> dependencies.

(see note below about packages)

> * Editions will most likely be implemented via an attribute on 
> the module declaration. We haven't discussed any details about 
> that, but for now, just imagine something like `@edition(2024) 
> module foo;`.

There are an awful lot of `version`s set by things that should be 
part of editions, but exactly how this is supposed to be 
implemented can be hashed out later.

They should also be ideally settable via a (say) an attribute, on 
the module declaration of a package and have that apply to the 
whole package. That way we limit a whole lot of redundant 
configuration.

> * Features cannot be opted into individually. When you apply an 
> edition to a module, you get the whole thing.

Well that's DoA then. Why bother to implement feature sets if you 
can't select them?
This is a particular problem from incompatible sets of features, 
which D has a not insignificant amount of ( betterC, basically 
all of the -preview flags), including things that affect 
safety/codegen like `-boundscheck`, `-check`, `-checkaction`, 
`-cov`.

Selectable features would solve the problem of "a dependancy uses 
an option I don't want to enable"

Implementing default combinations of features (editions) on top 
of selectable features would be reasonable.

> * The default edition, meaning the code you have now, should 
> compile forever.

I hope you mean "we will keep around old editions as (potentially 
command line) selectable options and we can update the default to 
be the current"

> * We should have a tool that automates as much as possible the 
> migration of modules to new editions
> * DMD-as-a-library is a critical component for that tool and 
> other tools in the ecosystem. We need to put a priority on 
> working out all the implementation issues Razvan has raised.
> * Given that much of the D community uses code-d, we need to 
> bring Jan Jurzitza into any discussions about DMD-as-a-library.

Yes, yes, yes.