On Tuesday, 14 November 2023 at 16:07:26 UTC, Mike Parker wrote:
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.
What do we want the first experience with D to be like?
A person trying out D, who writes a one-file simple application
using phobos *does not care* that a lib abandoned in 2018 still
compiles. So why should they be the ones paying the penalty?
I get that we want to stop breaking builds. But the answer there
is simple -- provide a way to do it by attributing the files, or
by telling the compiler "these files are edition X" or whatever.
And once you attribute it, it never breaks again. Sounds like a
reasonable cost to me for those who want long-lasting code!
There are other options here. Like use the filesystem to identify
the edition either via config or filenames.
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.
That's not any better. If you have to opt-in to the language as
it exists, people are going to quit immediately. I'm not joking
about this. Imagine spending 2 hours trying to figure out why
your app that is trying out some new feature doesn't compile,
only to find out after posting online that it was looking at some
ancient version of phobos.
-Steve