D Editions

[harakim]

On Thursday, 30 May 2024 at 18:31:48 UTC, Atila Neves wrote:
> https://github.com/atilaneves/DIPs/blob/editions/editions.md
>
> Destroy!

Editions, as outlined and discussed, will easily solve the most 
problematic issues. There are no compilation failures I have run 
into in the past few years that would have been hard to solve 
with editions as described. That means my experience (and anyone 
like me) would have been ideal during that time period, at only 
the cost that I have to specify the edition. That is a huge win.

There are lots of comments, such as:
"Mostly, yes, druntime will be kind of stuck."
"How does a newer edition with less @safe bugs treat @safe code 
from an older edition that has more memory safety holes?"

This is a completely reasonable fear. Suppose there is a feature 
that is not possible or practical to add in an edition. I don't 
think it's unreasonable to (rarely!) make a breaking change and 
start a new stream of editions. The situation will be much better 
than it is today where my code fails to compile after almost 
every compiler release. It would be important to put these 
changes off and make them all at once. So you have, for example, 
three years of stability and then three breaking changes at once, 
instead of one breaking change each year. You have to break some 
eggs if you want to make a omelette. If there are a few of these 
over the next few years, editions will be better than the current 
state during the meantime. And then the lessons learned will 
create a future where it doesn't need to happen as often. I can 
think of solutions to make this less painful than it is today. 
This proposal is good as is and if it isn't perfect, it's still a 
step in the right direction, with the potential to be nearly 
perfect in the future.

Now to comment specifically on the proposal, you said:
"Modules without a module declaration would be considered to be 
using the latest edition unless the default edition is specified 
explicitly with a command line argument."

That is the obvious sensible plan. The only issue I see with this 
is that is this scenario.
Timon Gehr said:
>>> How do you compile different modules with different editions 
>>> on the same command line?
>> 
>> You can attribute a module with the edition you are using to 
>> build.
>
> The whole point is not having to edit modules that were written 
> by someone else just to be able to import them.

In ten years, I don't want to have to remember the name of the 
first edition, not to mention the edition naming may get more 
complicated as things tend to do. Most code that is not annotated 
with an edition will be from the first edition so it almost seems 
like it should be the default. Except that it would obviously be 
annoying for the end user and a language feature a new programmer 
would need to know. So that is a no go. This needs a solution and 
I don't have a great one. Perhaps there is a flag like 
-edition=first or an easy way to look it up. It does not need to 
be a part of this proposal, but I think it will need to be a part 
of editions come two or three years.

As for version naming, let's say this is version 2 of the 
language. Then the first edition could be "2.1". And the next 
version could be 2.2. Once you need a truly breaking change, then 
the edition becomes 3.1 (or start with 2.0/3.0 because we are 
programmers.) This would be intuitive for someone to understand 
it's a different language version and needs a different tool. 
Although, regardless of edition naming, if you try to compile 
2024 code with a 2029 (incompatible) compiler, the compiler would 
easily be able to say "This needs such-and-such compiler" or 
other, simpler solutions I can think of for new users.