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