DLF September 2023 Planning Update
Dukc
ajieskola at gmail.com
Wed Nov 22 21:07:59 UTC 2023
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:
> In September 2023, we had one planning session. The major item
> on the agenda was editions. Other items were a new meeting
> format, the Bugzilla to GitHub migration, and the future of D.
>
> ## Attendees
> The following people attended the session.
>
> * Walter Bright
> * Ali Çehreli
> * Martin Kinkelin
> * Dennis Korpel
> * Átila Neves
> * Razvan Nitu
> * Mike Parker
> * Robert Schadek
>
> ## 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. 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.
These are excellent progress. I don't wholly agree with the
strong commitment on backwards compability DLF decided to make,
but with editions it doesn't matter much. The langauge can remain
both backwards compatible and develop further at the same time.
>
> 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.
Makes sense, but on the other hand we will have a lot of
questions about templates that are defined in domain of one
language edition and instantiated in another. It's going to be
onerous to figure out how those cases will work. Regardless, I'm
looking forward to this.
> * 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;`.
The syntax isn't critical anyway. That is one small detail that
won't have to dominate the discussions.
> * Features cannot be opted into individually. When you apply an
> edition to a module, you get the whole thing.
Makes sense again. Lifts a lot of maintenance burden for
relatively little user inconvenience. OTOH maybe the existing
preview/revert flags should stay for the starting version.
> * The default edition, meaning the code you have now, should
> compile forever.
> * We should have a tool that automates as much as possible the
> migration of modules to new editions
Isn't this what the `-transition` switches do? Regardless, mostly
agreed.
About the question of what would be the default edition. Like
others I tend to think that in cases where neither the module nor
the compiler invocation has any definitions it should be the
latest stable edition. Why? Adding `-edition=2023` (or whatever
the flag for the starting edition would be) to the build script
of a legacy project is dead simple, and besides needs to be done
only once, after which the project will always compile. People
don't hate breakage _that_ much.
The reverse situation, that we'd have to always either use
`-edition=20xx` or explicilty declare the edition in the module
header for new code would have the same problems that our
`@system` impure defaults for function attributes. At best, it'd
annoy people but more likely it'd more or less lead to new code
being written in the starting edition because we don't remember
or bother with picking the edition.
More information about the Digitalmars-d-announce
mailing list