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.
