DLF September 2023 Planning Update

[Mike Parker]

On Tuesday, 14 November 2023 at 15:05:34 UTC, Steven 
Schveighoffer wrote:
> On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:
>> * 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;`.
>
> When considering how this should work, I would strongly suggest 
> it be the default to work with the current edition of the 
> language. Nobody wants to always have to attribute their module 
> (or whatever other opt-in mechanism) to use current features. 
> It's going to be a WTF moment for all newcomers to D.
>
> This brings us to the problem that no prior libraries have 
> editions marked on them. So I think there needs to be an 
> external mechanism to be able to set the edition for a package 
> or module from the command line, or somehow in a config file. 
> Or you can set the "assumed" edition using a switch (but it 
> should still default to "current").
>

Experience with deprecations has shown people don't want to take 
extra steps to make their outdated dependencies compile. The goal 
with editions is that you should never have to take any extra 
steps to use older code in your program. You can't do that if the 
default edition changes with every new compiler release. But you 
can do that if each module explicitly declares which edition it 
needs.

An option to specify the latest edition via the attribute came up 
in our discussions, so I'm sure we'll have that. And I anticipate 
there'll be some way to generate source files with the 
appropriately decorated module declarations, probably through 
third-party tools like code-d, maybe from a tool that ships with 
(or is built into) the compiler.