https://github.com/atilaneves/DIPs/blob/editions/editions.md

On Tuesday, 1 April 2025 at 16:21:59 UTC, Atila Neves wrote:

Glad to see you are still working on this.

Two lines might need some clarification:

1. "One possibly way to bound this complexity could be to only support the last N editions, for N < 5."

2. "The editions feature is explicitly designed with the goal of not introducing any breaking changes or deprecations. Existing D code that does not opt-in will continue to compile as behave as before."

My reading is that if you don't opt-in to a specific edition, then you use the current edition. So #2 is a little confusing because if new editions introduce breaking changes, then you have to opt-in to use the prior edition to avoid the breakage.

If you have opted-in to editions and you are only keeping around the last N editions, then when the number of editions is larger than N, support for initial editions will get dropped. This also implies that there will be breaking changes/deprecations.

If you really want to avoid breaking changes/deprecations, you can also keep last N editions plus the initial edition. You can also optionally strike new ones every couple of years that are meant to be kept around. That last bit depends on how often we get these new editions.

In the paragraph below you say "current original edition" but I think you just mean "current edition". The last sentence could probably be folded into the first sentence, or otherwise simplified since it covers a bit of what is in the first sentence.

Existing modules without this optional declaration but that have a module declaration are considered to target the current original edition. That is: they will be compiled as if the editions feature did not exist. 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.

On Tuesday, 1 April 2025 at 16:21:59 UTC, Atila Neves wrote:

D is not go/rust/c++/c#, can it afford this much maintenance burden that editions will bring? I personally don't think so

On Tuesday, 1 April 2025 at 16:21:59 UTC, Atila Neves wrote:

Why? I see no reason that they shouldn't behave like the modules with editionless declaration at the top.

Does this override the edition at the module declaration?

Of course they have to support the new edition, but why would they have to transition to the edition themselves? Seems extra work for no good reason.

All in all, I strongly support this DIP.

On Wednesday, 2 April 2025 at 12:52:59 UTC, Dukc wrote:

I think this might be my fault. In a long-ago review of the original editions, my concern was about playground code, or simply trying out the langauge.

Instead of having to first learn how to specify editions, one should be able to use the language as it is currently specified.

Basically, if you write a hello world program, or play with features, they should operate as documented, not as they were 2, 3, 10 years ago.

My recommendation was that the compiler would default to using the current edition, if no edition was specified on the module. However, dub would behave differently and specify a default edition that is the pre-edition edition. This way, the thousands of dub configurations out there that existed before editions existed would default to the language at that level.

However, it seems this proposal goes a step further, and I agree, a confusing one. It is not hard to evolve playground code into a level that requires adding module declarations. I don't see why these need to be for the OG edition.

I think the default edition if none is specified should always be the latest. You can always change that with a compiler switch.

I would say no. The purpose of this is for build systems to allow setting the default edition package-wide.

Think of a dub package you are using that uses edition 2025, but you are on edition 2026. There are no edition specifiers in the modules, it's done all through the build system (dub). So when you import those modules, you need to specify the default edition just for those imports.

-Steve

On Tuesday, 1 April 2025 at 16:21:59 UTC, Atila Neves wrote:

Perl's use version should be included as prior work. Perl has use feature, so if you want to add a modernized version of the say function, you add use feature 'say' to your script. Versions have feature bundles, so use 5.24.1 is the same as adding use feature for every feature in the bundle.

I think that should be decided at the time the edition is added. For instance, one of your examples is @safe by default. If instead there was an edition with @system by default, that would amount to certain checks not being done, and I don't think skipping checks in the compiler will make the compiler complexity explode even after many editions. I'm sure other editions would greatly complexify the compiler, so there should be a limit on the number of releases they're supported. I guess my point is that dropping editions after a certain number of releases should only be done if there's a strong justification.

On Monday, 7 April 2025 at 15:20:54 UTC, Lance Bachmeier wrote:

Forgot to add: use feature has been in Perl since 5.10, so they have 17 years of experience working with it, and that may provide us with some guidance as to what does and doesn't work in practice. I no longer write much Perl so I can't offer any opinions.

On Monday, 7 April 2025 at 03:43:58 UTC, Steven Schveighoffer wrote:

It seems I got this question a bit wrong. I somehow thought Átila was proposing that no declaration => current edition, editionless declaration => one specified by switch, the latest one by default. But in fact the DIP proposes the reverse.

So to be clear IMO the latest edition should always be the default. Not the present one. It's dead easy to add -edition=2025 to the command line parameters if you're compiling old code sometime in the future. Getting people to consistently use the latest edition when the default is something else is much harder.