DLF September 2023 Planning Update

[Steven Schveighoffer]

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