On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:

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").

-Steve

On Tuesday, 14 November 2023 at 15:05:34 UTC, Steven Schveighoffer wrote:

Worth noting that this is exactly how GCC handles different revisions of the C and C++ standards. [1] It defaults to -std=gnu18 (C17 with GNU extensions) and -std=gnu++17 (C++17 with GNU extensions), which are the most recent versions that are fully implemented, but older versions (and previews of newer ones!) can be selected on the command line.

D's philosophy of making the safe, recommended choice the default has served it well for features like bounds checking, default initialization, assertions, etc. I hope very much that the same philosophy will be applied to editions.

[1] https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/C-Dialect-Options.html

On Tuesday, 14 November 2023 at 15:05:34 UTC, Steven Schveighoffer 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.

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.

On Tuesday, 14 November 2023 at 16:07:26 UTC, Mike Parker wrote:

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.

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

On Tuesday, 14 November 2023 at 15:05:34 UTC, Steven Schveighoffer wrote:

+1 and only the introduction of edition has this problem, it's a one time cost for the ecosystem.

On Tuesday, 14 November 2023 at 18:01:36 UTC, Guillaume Piolat wrote:

+1 too

On Tuesday, 14 November 2023 at 17:57:36 UTC, Steven Schveighoffer wrote:

Counterpoint: javascript's "use strict".

On the gripping hand though, I basically never use that and most people prolly don't either. But it is a major language example we ought to consider.

But for existing libraries, I actually have a potential solution for that: made dub look at the version tag date.

So, suppose dub determines it wants to use abandoned-library version 1.4. It knows version 1.4 was tagged on December 25, 2016.

This could automatically go ahead and add -edition=abandoned.library=2.092 to the build command for that lib.

Notice that build command used a package specifier, if an edition is specified on the command line, it MUST be scoped to a specific module (or D package, just like how -i works) so when it is imported, the compiler can attach the edition tag there without affecting other things in the build.

It would basically work like you pass -edition=abandoned.library=2.092 on the cmd line and the compiler acts exactly the same as if you wrote @edition(2.092) when it sees module abandoned library.

On the other hand, suppose dub sees a new tag, version 2.0, created in 2024. This will be edition 2.107 since it has a date range to version map.

We'd have to work out the exact details, but just since dub knows the tag date it can make a pretty good automatic guess as to the proper version.

On Tuesday, 14 November 2023 at 17:57:36 UTC, Steven Schveighoffer wrote:

Ergonomically it potentially doesn't have to be quite so binary e.g. a C++ compiler will tell you to opt-in to a new language version rather than just erroring.

But, if you have the logic to do that, you can also infer an older edition to keep the abandonware working even though by default you get the most recent one.

On Tuesday, 14 November 2023 at 18:40:58 UTC, Adam D Ruppe wrote:

The absence of "use strict" does not prevent you from using latest features. If you use the later features, it infers you meant "use strict". As I understand the current thinking, that is not what D is intending to do.

This could potentially work for D editions -- if you use a newer syntax/feature, then you have opted into that version of the language? But I am not sure this is worth the complication. Much easier to do the dumb thing and require specification.

Does "use strict" involve library API changes?

-Steve