www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DLF September 2023 Planning Update

reply Mike Parker <aldacron gmail.com> writes:
In September 2023, we had one planning session. The major item on 
the agenda was editions. Other items were a new meeting format, 
the Bugzilla to GitHub migration, and the future of D.


The following people attended the session.

* Walter Bright
* Ali Çehreli
* Martin Kinkelin
* Dennis Korpel
* Átila Neves
* Razvan Nitu
* Mike Parker
* Robert Schadek


We had agreed in [the September monthly 
meeting](https://forum.dlang.org/post/hetwfhikjqwzlvywmyzc forum.dlang.org) the
week before that we need to define what editions will look like before we start
deciding which features should go in any given edition. My goal with this
session was to establish the first point on the timeline: a deadline for the
editions proposal. I also thought it would be a good opportunity for all of us
to clarify what editions are (there were some different ideas about that) and
discuss aspects of the concept we need to consider.

Here are some points that came out of the discussion.

* Editions are essentially feature sets. Each edition can 
add/remove/deprecate features.
* Editions are entirely opt-in and only affect the source you 
explicitly apply them to, i.e., they are not transitive to 
dependencies.
* Editions will most likely be implemented via an attribute on 
the module declaration. We haven't discussed any details about 
that, but for now, just imagine something like ` edition(2024) 
module foo;`.
* Features cannot be opted into individually. When you apply an 
edition to a module, you get the whole thing.
* The default edition, meaning the code you have now, should 
compile forever.
* We should have a tool that automates as much as possible the 
migration of modules to new editions
* DMD-as-a-library is a critical component for that tool and 
other tools in the ecosystem. We need to put a priority on 
working out all the implementation issues Razvan has raised.
* Given that much of the D community uses code-d, we need to 
bring Jan Jurzitza into any discussions about DMD-as-a-library.

Átila took on the job of writing the proposal and we set November 
1st as the deadline. We've since moved it to mid-December.

One thing I'm looking forward to: editions will provide us with a 
framework to clearly define a roadmap for the language and the 
library.


Our monthly and quarterly meetings have no fixed agendas. These 
are opportunities for each participant to report what they're 
working on and raise issues they'd like to see resolved. Our 
planning sessions are shorter, more focused meetings in which we 
resolve or decide how to proceed with a specific set of agenda 
items. I proposed we start having what I called "workgroup 
sessions", meetings aimed at hammering out details on bigger 
problems that can't be resolved in one meeting or by one person.

DMD-as-a-library was a good example. This project had been in the 
works in one form or another for years. Razvan has been making an 
effort to get it to the finish line, but there were some critical 
issues to resolve in terms of interface and implementation. It 
took a large chunk of time in our September monthly meeting and 
external conversations with no resolution. Complex issues like 
this need a group of stakeholders focused on hammering out the 
details.

We agreed I should set up a meeting. I noted who was interested 
in participating and took suggestions for other invitations.

We ended up having two DMD-as-a-library meetings in October. I 
didn't participate, but I'll post an update on the outcome.


I've already written about this as an update note in the 
September monthly meeting summary, but this was the session where 
we agreed that Robert should be running the migration script 
instead of me. He just needed admin access to our GitHub 
repositories, and there were no objections to granting it. We 
agreed with Robert's proposal to migrate the VisualD issues 
first, then each project in order from lowest to highest issue 
count.

I'll have more on this in upcoming summaries and updates.


Robert had been itching to talk about our long-term plans for D. 
I think most of us understood that he was talking in terms of 
language features, but in this session, he explained that's not 
what he meant. D started as a successor to C and C++, but he 
doesn't see the language that way. He sees it as the best parts 
of C, Haskell, and Python. Others may see it differently. So how 
do we define the language going forward? What role do we want it 
to play? Are we mostly concerned with C-style stuff where every 
bit counts? Do we see D as a great tool for one-off scripts that 
would normally be written in something like Python?

This prompted Walter to introduce the first draft of his 
Didactica, a list of the principles behind the language. That's 
the kind of thing Robert was looking for. Everyone looked them 
over and provided feedback.

As I noted in the September monthly meeting summary, Walter has 
since gone through multiple drafts of this list. Though he 
originally saw it as a set of principles behind the language, 
he's now come to see it more as the principles behind the DLF, 
guiding not just the development of the language, but also the 
ecosystem, community resources, and so on.

Once it's finalized, this list and the DLF's IVY statement should 
together serve as an aspirational filter for evolving the 
language, the ecosystem, and the community. Does a proposed 
language feature align? Is a current feature not in alignment? 
Are we falling short of our principles in any specific area?



We ended with a non-agenda discussion on expanding BuildKite to 
test more code.dlang.org packages to further reduce breakage with 
new compiler releases. The current list is manually curated. 
Átila has a script that determines which code.dlang.org projects 
currently build, and that results in a bigger list. The only 
actionable item that came out of this is that Robert will write a 
script to work out the dependency graph from that list in the 
hope it can be used to minimize the time taken to run the tests 
and reduce resource usage.
Nov 14 2023
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:


 We had agreed in [the September monthly 
 meeting](https://forum.dlang.org/post/hetwfhikjqwzlvywmyzc forum.dlang.org)
the week before that we need to define what editions will look like before we
start deciding which features should go in any given edition.


Good


 My goal with this session was to establish the first point on 
 the timeline: a deadline for the editions proposal. I also 
 thought it would be a good opportunity for all of us to clarify 
 what editions are (there were some different ideas about that) 
 and discuss aspects of the concept we need to consider.

 Here are some points that came out of the discussion.

 * Editions are essentially feature sets. Each edition can 
 add/remove/deprecate features.
 * Editions are entirely opt-in and only affect the source you 
 explicitly apply them to, i.e., they are not transitive to 
 dependencies.


(see note below about packages)


 * Editions will most likely be implemented via an attribute on 
 the module declaration. We haven't discussed any details about 
 that, but for now, just imagine something like ` edition(2024) 
 module foo;`.


There are an awful lot of `version`s set by things that should be 
part of editions, but exactly how this is supposed to be 
implemented can be hashed out later.

They should also be ideally settable via a (say) an attribute, on 
the module declaration of a package and have that apply to the 
whole package. That way we limit a whole lot of redundant 
configuration.


 * Features cannot be opted into individually. When you apply an 
 edition to a module, you get the whole thing.


Well that's DoA then. Why bother to implement feature sets if you 
can't select them?
This is a particular problem from incompatible sets of features, 
which D has a not insignificant amount of ( betterC, basically 
all of the -preview flags), including things that affect 
safety/codegen like `-boundscheck`, `-check`, `-checkaction`, 
`-cov`.

Selectable features would solve the problem of "a dependancy uses 
an option I don't want to enable"

Implementing default combinations of features (editions) on top 
of selectable features would be reasonable.


 * The default edition, meaning the code you have now, should 
 compile forever.


I hope you mean "we will keep around old editions as (potentially 
command line) selectable options and we can update the default to 
be the current"


 * We should have a tool that automates as much as possible the 
 migration of modules to new editions
 * DMD-as-a-library is a critical component for that tool and 
 other tools in the ecosystem. We need to put a priority on 
 working out all the implementation issues Razvan has raised.
 * Given that much of the D community uses code-d, we need to 
 bring Jan Jurzitza into any discussions about DMD-as-a-library.


Yes, yes, yes.
Nov 14 2023
parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 14 November 2023 at 08:55:22 UTC, Nicholas Wilson 
wrote:


 I hope you mean "we will keep around old editions as 
 (potentially command line) selectable options and we can update 
 the default to be the current"


No. The whole point is that old code will continue to compile 
without any special flags. We want to get out of this situation 
where an old but useful library stops compiling just because you 
use a newer compiler version on your project. The default edition 
doesn't change.
Nov 14 2023
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:

 In September 2023, we had one planning session. The major item 
 on the agenda was editions. Other items were a new meeting 
 format, the Bugzilla to GitHub migration, and the future of D.

 [...]


Great summary. From the user side of things I think our best 
options are code-d and Visual D, but I haven't heard so much 
about Visual D-development plans. Do you know if there are any?

Thanks!
Nov 14 2023
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 14 November 2023 at 09:51:29 UTC, Imperatorn wrote:


 Great summary. From the user side of things I think our best 
 options are code-d and Visual D, but I haven't heard so much 
 about Visual D-development plans. Do you know if there are any?

 Thanks!


You'll have to ask Rainer about his plans for Visual D. I haven't 
chatted with him in a long while.
Nov 14 2023
parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 14 November 2023 at 10:31:54 UTC, Mike Parker wrote:

 On Tuesday, 14 November 2023 at 09:51:29 UTC, Imperatorn wrote:


 Great summary. From the user side of things I think our best 
 options are code-d and Visual D, but I haven't heard so much 
 about Visual D-development plans. Do you know if there are any?

 Thanks!


 You'll have to ask Rainer about his plans for Visual D. I 
 haven't chatted with him in a long while.


And I should add that at some point, I do hope to be able to tell 
people about plans for Visual D. That's one of the projects we 
need to think about once we start discussion broader ecosystem 
plans.
Nov 14 2023
prev sibling next sibling parent reply Andrey Zherikov <andrey.zherikov gmail.com> writes:
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:




Did you see this video from cppnow'23? 
https://youtu.be/VMYVbA2gg0g?si=fMGbnE0FliLwmYgo
It's a good talk about language evolution in general.
Nov 14 2023
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 14 November 2023 at 12:55:28 UTC, Andrey Zherikov 
wrote:

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




 Did you see this video from cppnow'23? 
 https://youtu.be/VMYVbA2gg0g?si=fMGbnE0FliLwmYgo
 It's a good talk about language evolution in general.


Haven't seen that one, but there's certainly a lot of interest in 
the C++ community on language evolution.

 From the same conference, this one on the Carbon language is kind 
of in line with the work on editions
https://www.youtube.com/watch?v=1ZTJ9omXOQ0

I also enjoyed Herb's discussion of language evolution at the 
latest CppCon
https://www.youtube.com/watch?v=8U3hl8XMm8c&list=PLHTh1InhhwT7gQEuYznhhvAYTel0qzl72&index=4
Nov 14 2023
prev sibling next sibling parent Andrey Zherikov <andrey.zherikov gmail.com> writes:
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:




Did you take a look at other languages and how they implement 
this feature? May be there is a language that already implements 
the approach your are looking for and you don't need to reinvent 
a wheel?
What I'd like to see is something like "we took a look at 
languages A,B and C and we decided that editions should work that 
way because X, Y and Z" or "editions should work the same way as 
in language A"

There will always be two requests and you'll have to provide a 
solution (tbh I don't see how to make everyone happy here):
- I want my old code to be built with the latest compiler the 
same way forever.
- I want to evolve my code together with the language and 
compiler.
Nov 14 2023
prev sibling next sibling parent reply Andrey Zherikov <andrey.zherikov gmail.com> writes:
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:

 * We should have a tool that automates as much as possible the 
 migration of modules to new editions
 * DMD-as-a-library is a critical component for that tool and 
 other tools in the ecosystem. We need to put a priority on 
 working out all the implementation issues Razvan has raised.


IMHO having a general purpose migration tool is a big win. For 
example, I, as a library owner, want to help users to migrate 
their code from one library version to another and making this 
code evolution automatic would be ideal.
Nov 14 2023
parent matheus <matheus gmail.com> writes:
On Tuesday, 14 November 2023 at 13:25:43 UTC, Andrey Zherikov 
wrote:

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

 * We should have a tool that automates as much as possible the 
 migration of modules to new editions
 * DMD-as-a-library is a critical component for that tool and 
 other tools in the ecosystem. We need to put a priority on 
 working out all the implementation issues Razvan has raised.


 IMHO having a general purpose migration tool is a big win. For 
 example, I, as a library owner, want to help users to migrate 
 their code from one library version to another and making this 
 code evolution automatic would be ideal.


I know this is kind of a different subject, but one thing that 
I'd like to understand is this situation of evolution. We usually 
see people complaining about the language evolution vs breaking 
code.

I wonder how hard would be to "fix" the old code with a tool 
during the compile time. For example I see this with VSCode 
Editor when opening on old code and it shows some suggestions to 
fix the code with, of course it's not during the compile time but 
it's parsed somehow through the IDE (I guess!?).

Well I barely see this in some languages, and I always wondered 
why? I mean why a source couldn't be parsed and fixed (With the 
user approval) in one go.

Matheus.
Nov 14 2023
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:

 * Editions will most likely be implemented via an attribute on 
 the module declaration. We haven't discussed any details about 
 that, but for now, just imagine something like ` edition(2024) 
 module foo;`.


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
Nov 14 2023
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Tuesday, 14 November 2023 at 15:05:34 UTC, Steven 
Schveighoffer 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").


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
Nov 14 2023
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 14 November 2023 at 15:05:34 UTC, Steven 
Schveighoffer wrote:

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

 * Editions will most likely be implemented via an attribute on 
 the module declaration. We haven't discussed any details about 
 that, but for now, just imagine something like ` edition(2024) 
 module foo;`.


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


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.
Nov 14 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Nov 14 2023
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 14 November 2023 at 17:57:36 UTC, Steven 
Schveighoffer wrote:

 That's not any better. If you have to opt-in to the language as 
 it exists, people are going to quit immediately.


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.
Nov 14 2023
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Tuesday, 14 November 2023 at 18:40:58 UTC, Adam D Ruppe wrote:

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

 That's not any better. If you have to opt-in to the language 
 as it exists, people are going to quit immediately.


 Counterpoint: javascript's "use strict".


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
Nov 14 2023
parent reply Dennis <dkorpel gmail.com> writes:
On Tuesday, 14 November 2023 at 19:13:38 UTC, Steven 
Schveighoffer wrote:

 As I understand the current thinking, that is not what D is 
 intending to do.


Additional changes don't require a new edition to be enabled, 
only breaking changes. I expect editions to mostly subtract code, 
by turning existing deprecations into errors and enabling preview 
switches like nosharedaccess, dip1000, fixImmutableConv, 
systemVariables.
Nov 14 2023
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Tuesday, 14 November 2023 at 20:09:53 UTC, Dennis wrote:

 On Tuesday, 14 November 2023 at 19:13:38 UTC, Steven 
 Schveighoffer wrote:

 As I understand the current thinking, that is not what D is 
 intending to do.


 Additional changes don't require a new edition to be enabled, 
 only breaking changes. I expect editions to mostly subtract 
 code, by turning existing deprecations into errors and enabling 
 preview switches like nosharedaccess, dip1000, 
 fixImmutableConv, systemVariables.


This sounds like it's not the mechanism being envisioned for 
modifying phobos or druntime.

Looking forward to the full description!

-Steve
Nov 15 2023
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 14 November 2023 at 18:40:58 UTC, Adam D Ruppe wrote:

 [snip]

 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.


To bikeshed a little, dub has the concept of `subConfigurations` 
that you use to pass a configuration to a dependency. This is 
kind of like a `subEdition` so `subEdition "abandoned.library" 
2.092. Or something like that would be a bit more consistent.
Nov 14 2023
prev sibling next sibling parent max haughton <maxhaton gmail.com> writes:
On Tuesday, 14 November 2023 at 17:57:36 UTC, Steven 
Schveighoffer wrote:

 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


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.
Nov 14 2023
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 14 November 2023 at 17:57:36 UTC, Steven 
Schveighoffer wrote:

 [snip]
 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


You are describing my first attempt to attempt to use "modern 
C++" features. Certainly didn't want me to learn any more C++.
Nov 14 2023
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 14 November 2023 at 17:57:36 UTC, Steven 
Schveighoffer wrote:


 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.


You won't have to spend two hours figuring out. If you use a 
feature from a later edition, the compiler will give you an error 
and tell you what you need to do.

I think it's much more frustrating to pull down a new version of 
the compiler and find your current project breaks. You shouldn't 
have to change your code or adjust your build system to use a new 
version of the compiler. It should just work.
Nov 14 2023
prev sibling parent reply Guillaume Piolat <first.name gmail.com> writes:
On Tuesday, 14 November 2023 at 15:05:34 UTC, Steven 
Schveighoffer 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


+1 and only the introduction of edition has this problem, it's a 
one time cost for the ecosystem.
Nov 14 2023
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Tuesday, 14 November 2023 at 18:01:36 UTC, Guillaume Piolat 
wrote:

 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.


+1 too
Nov 14 2023
parent reply Sergey <kornburn yandex.ru> writes:
On Tuesday, 14 November 2023 at 18:24:09 UTC, Paolo Invernizzi 
wrote:

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

 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.


 +1 too


+1 to Steven’s approach

Idk why DLF don’t like KISS approach :(
Nov 14 2023
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, November 14, 2023 12:37:29 PM MST Sergey via Digitalmars-d-
announce wrote:

 +1 to Steven’s approach

 Idk why DLF don’t like KISS approach :(


Their focus is on allowing existing dub packages to continue to compile
without any effort whatsoever on the part of anyone using them, because the
breakage of dub packages over time as the language changes has become a
serious issue (that's the main reason that they started looking at doing
editions in the first place). Whether that's the right approach is certainly
debatable (and personally, I'd rather see something in dub take care of it
rather than require that new code slap editions stuff everywhere), but there
is a good reason for the approach that they're currently looking at taking.

- Jonathan M Davis
Nov 15 2023
parent reply Sergey <kornburn yandex.ru> writes:
On Wednesday, 15 November 2023 at 09:27:53 UTC, Jonathan M Davis 
wrote:

 On Tuesday, November 14, 2023 12:37:29 PM MST Sergey via 
 Digitalmars-d- announce wrote:

 +1 to Steven’s approach

 Idk why DLF don’t like KISS approach :(


 Their focus is on allowing existing dub packages to continue to 
 compile without any effort whatsoever on the part of anyone 
 using them, because the breakage of dub packages over time as 
 the language changes has become a serious issue (that's the 
 main reason that they started looking at doing editions in the 
 first place).


Maybe I didn't understand the approach.
like let's assume several editions already in place (and we are 
in 2030) and the project has several dependencies:
- main code (works with latest version. Latest edition)
- depmain.1 (work only with edition 2022)
- depmain.2 (work only with edition 2023)
  |- dep2.1 (work with editions 2023-2027)
  |- dep2.2 (work only with edition 2029)

So instead of force users to explicitly specify editions in 
dub.jsons - DLF propose to use just "dub build" (without any 
changes in code of dependency packages and main project) and 
somehow each edition should be identified for each package?


 Whether that's the right approach is certainly debatable (and 
 personally, I'd rather see something in dub take care of it 
 rather than require that new code slap editions stuff 
 everywhere), but there is a good reason for the approach that 
 they're currently looking at taking.

 - Jonathan M Davis


I think when Grim was ranting about breaking changes and how hard 
for him fixing it - he meant fixing real code, and I would be 
quite surprise if for him it will be hard to add into his 
dub.json/sdl 1 line:
"edition" : ["D2022"]
Nov 15 2023
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, November 15, 2023 3:26:27 AM MST Sergey via Digitalmars-d-
announce wrote:

 On Wednesday, 15 November 2023 at 09:27:53 UTC, Jonathan M Davis

 wrote:

 On Tuesday, November 14, 2023 12:37:29 PM MST Sergey via

 Digitalmars-d- announce wrote:

 +1 to Steven’s approach

 Idk why DLF don’t like KISS approach :(


 Their focus is on allowing existing dub packages to continue to
 compile without any effort whatsoever on the part of anyone
 using them, because the breakage of dub packages over time as
 the language changes has become a serious issue (that's the
 main reason that they started looking at doing editions in the
 first place).


 Maybe I didn't understand the approach.
 like let's assume several editions already in place (and we are
 in 2030) and the project has several dependencies:
 - main code (works with latest version. Latest edition)
 - depmain.1 (work only with edition 2022)
 - depmain.2 (work only with edition 2023)

   |- dep2.1 (work with editions 2023-2027)
   |- dep2.2 (work only with edition 2029)

 So instead of force users to explicitly specify editions in
 dub.jsons - DLF propose to use just "dub build" (without any
 changes in code of dependency packages and main project) and
 somehow each edition should be identified for each package?


As I understand it, the language that we have now (or whatever it is when
editions are actually added) will be the default edition, and any code
wanting to build with a newer edition will have to specify it in the source
code. So, existing code will continue to compile how it does now
theoretically forever, and new code that gets written and wants to use a
newer edition will then specify the edition that it wants to use in each
module, so it will continue to compile with that edition forever. Code can
of course be updated to use a newer edition, but the edition that it uses
will never change unless the code is changed, so it will theoretically all
continue to compile the same way that it always has. It does come with the
downside of having to slap an attribute on your code to use the latest
version of the language, but it means that code will continue to compile the
same way that it always has with no effort regardless of what is done with
future editions.

In contrast, if the default edition is the latest, then code will
potentially break as new editions are released, forcing code to be changed
over time in order to continue to compile (even if it's just adding an
edition attribute to it to force the old behavior), and as we've seen with
deprecations, plenty of folks don't want to bother updating their code until
they have to (and that's assuming that the code is even still maintained,
which can be a real problem with dependencies). The problem could be
mitigated by doing stuff with dub (be it by specifying the edition that you
want to build a dependency with or by having dub figure it out based on when
the code was last updated), but we would have to put in extra work of some
kind to then make old code compile again instead of having it just compile
forever the same way that it always has.

Both approaches have pros and cons. The approach that they currently seem to
want to go with is aimed at keeping code compiling with no effort, which
should keep dub packages working long term, whereas right now, we have
issues with them breaking over time depending on how well they're
maintained. And since it's issues with that that are the primary motivators
behind editions in the first place (e.g. some of the companies using D
depend on packages - potentially many packages - from code.dlang.org, and
it's definitely becoming a problem when some of them aren't kept up-to-date
with the latest language changes). So, it's not terribly surprising that
that's what Walter and Atila would favor.

Of course, that does make writing new code more annoying, which is part of
why there are objections to it. It also makes it much more likely that a lot
of code will just be written for the old version of the language instead of
the latest, which could cause issues. So, it's hard to say which approach is
better.

And of course, regardless of how we deal with specifying editions and which
the default is, we still have the question of whether they're actually going
to manage to make it sane to mix editions (which you'll inevitably do when a
dependency uses a different edition), since features like type introspection
(which D code typically uses quite heavily) are likely to make it pretty
hard to actually implement. So, we'll have to see what they actually manage
to come up with.

- Jonathan M Davis
Nov 15 2023
parent Andrey Zherikov <andrey.zherikov gmail.com> writes:
On Wednesday, 15 November 2023 at 11:05:03 UTC, Jonathan M Davis 
wrote:

 So, we'll have to see what they actually manage to come up with.


I guess this is the only way to understand the idea of how this 
should work.
Nov 15 2023
prev sibling next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:


 Robert had been itching to talk about our long-term plans for 
 D. I think most of us understood that he was talking in terms 
 of language features, but in this session, he explained that's 
 not what he meant. D started as a successor to C and C++, but 
 he doesn't see the language that way. He sees it as the best 
 parts of C, Haskell, and Python. Others may see it differently. 
 So how do we define the language going forward? What role do we 
 want it to play? Are we mostly concerned with C-style stuff 
 where every bit counts? Do we see D as a great tool for one-off 
 scripts that would normally be written in something like Python?



D is not and has never been a c replacement language, your not 
Zig, there's a very real dependency on gc(and no  nogc/betterc 
doesn't change that, you have first-class dynamic arrays based on 
the gc) theres a grand total of 3 platforms where d is stable and 
it will never be the portable asm of C; no embedded, no gnu, no 
unix, and no credible aspirations to change that.

D *is* a c++ replacement, c++ isn't very good at its job, and 
while I dont know how somehow aa managed to convince walter to 
merge in lots of quality of life stuff for the template hell. 
Please focus on making the template hell, survivable and either 
take it upon yourself to make the stl or enable its conditions.

D isn't haskell, sumtypes aren't even a first-class abstraction I 
simply don't know what someone could've said that made that on 
the table.

~~python sucks and is irrelevant ~~
Nov 14 2023
parent reply Mike Shah <mshah.475 gmail.com> writes:
On Tuesday, 14 November 2023 at 21:13:34 UTC, monkyyy wrote:

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


 Robert had been itching to talk about our long-term plans for 
 D. I think most of us understood that he was talking in terms 
 of language features, but in this session, he explained that's 
 not what he meant. D started as a successor to C and C++, but 
 he doesn't see the language that way. He sees it as the best 
 parts of C, Haskell, and Python. Others may see it 
 differently. So how do we define the language going forward? 
 What role do we want it to play? Are we mostly concerned with 
 C-style stuff where every bit counts? Do we see D as a great 
 tool for one-off scripts that would normally be written in 
 something like Python?



 D is not and has never been a c replacement language, your not 
 Zig, there's a very real dependency on gc(and no  nogc/betterc 
 doesn't change that, you have first-class dynamic arrays based 
 on the gc) theres a grand total of 3 platforms where d is 
 stable and it will never be the portable asm of C; no embedded, 
 no gnu, no unix, and no credible aspirations to change that.

 D *is* a c++ replacement, c++ isn't very good at its job, and 
 while I dont know how somehow aa managed to convince walter to 
 merge in lots of quality of life stuff for the template hell. 
 Please focus on making the template hell, survivable and either 
 take it upon yourself to make the stl or enable its conditions.

 D isn't haskell, sumtypes aren't even a first-class abstraction 
 I simply don't know what someone could've said that made that 
 on the table.

 ~~python sucks and is irrelevant ~~



Do we see D as a great tool for one-off scripts that would 
normally be written in something like Python?


D has replaced every single file Python script that I use. Fast 
build times (DMD), multiple programming paradigms, and 
concurrency support are huge wins for D over languages like 
Python.

The major advantage with D (over Python) is building/maintaining 
scalable applications (i.e. more than one file, but several 
thousand or hundred thousand lines of code).  Talking to several 
engineers over that past few years in a few big tech companies -- 
they have spent a significant amount of time rewriting their code 
from Python to C++ because of issues with Python (performance and 
dynamic typing being culprits in Python). Too bad they did not 
start with D to avoid a rewrite! :)


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 just want to echo Steve's sentiment, that it should be easy for 
new (and old) D users to start up a project without worrying 
about editions. Reducing friction is incredibly important for 
adoption and usage. If the library writer specifies the 'edition' 
within their own module and it's totally encapsulated, that seems 
fine -- I think that is what I understand from the editions 
proposal (and if they don't specify the edition, it defaults to 
whatever the compilers default edition is).

I'd be curious to hear what folks working on tooling (IDE, 
linters, etc.) concerns are with editions. Having more tooling 
support is the main request I hear from students (Again, maybe 
this is already answered with DMD as a library in progress).
Nov 14 2023
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 15 November 2023 at 02:27:42 UTC, Mike Shah wrote:

 I just want to echo Steve's sentiment, that it should be easy 
 for new (and old) D users to start up a project without 
 worrying about editions.


Actually, this brings another question to mind: what about old 
users who keep up with the language? Do they need to edit dozens 
or hundreds of files on each and every language update? (Of 
course, making a script do this for you wouldn't be especially 
difficult, but I don't trust scripts to edit my code soooooo lol 
and besides, what about things like ddoc examples, will it edit 
them too?)

I actually rarely need to edit my code in response to new dmd 
versions now, and they remain compatible across users with old 
and new compilers alike. Would be a pity to throw that off.
Nov 14 2023
parent Mike Parker <aldacron gmail.com> writes:
On Wednesday, 15 November 2023 at 02:38:38 UTC, Adam D Ruppe 
wrote:

 On Wednesday, 15 November 2023 at 02:27:42 UTC, Mike Shah wrote:

 I just want to echo Steve's sentiment, that it should be easy 
 for new (and old) D users to start up a project without 
 worrying about editions.


 Actually, this brings another question to mind: what about old 
 users who keep up with the language? Do they need to edit 
 dozens or hundreds of files on each and every language update? 
 (Of course, making a script do this for you wouldn't be 
 especially difficult, but I don't trust scripts to edit my code 
 soooooo lol and besides, what about things like ddoc examples, 
 will it edit them too?)


The goal is that you will never have to touch those dozens or 
hundreds of files when you update to a new version of the 
compiler. That old code will benefit from any bug fixes in the 
newest compiler versions, but will always compile.

If and when you're ready to make use of a new feature from a 
newer edition, e.g., tuples from Edition N, then you take three 
steps:

1. fork your project
2. run the fix tool on however many modules/packages you 
want/need to
3. manually touch up whatever the fix tool couldn't handle 
automatically

That should cover any modifications required for changed/removed 
features, and now you can use tuples in those updated modules.

That's the idea, anyway, as I currently understand it.
Nov 14 2023
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 15 November 2023 at 02:27:42 UTC, Mike Shah wrote:


 I just want to echo Steve's sentiment, that it should be easy 
 for new (and old) D users to start up a project without 
 worrying about editions. Reducing friction is incredibly 
 important for adoption and usage. If the library writer 
 specifies the 'edition' within their own module and it's 
 totally encapsulated, that seems fine -- I think that is what I 
 understand from the editions proposal (and if they don't 
 specify the edition, it defaults to whatever the compilers 
 default edition is).


It's just like any other language feature you have to learn. The 
documentation will be clearly divided by edition. You'll have one 
section for the base language (the default edition) and one for 
each subsequent edition. You can jump in an use the default 
language without caring about editions. Then when you want to 
learn more, say sumtypes and tuples from edition N, the 
documentation, tutorials, and example code you see should make it 
very clear that you need to specify edition N. And the 
documentation for edition N will explain all the changes that 
edition makes.

If someone misses all of that and tries to use tuples without 
specifying edition N, the compiler should be able to tell them 
what the problem is, how to solve it (annotate your module 
declaration with ` edition(N)`), and provide the URL to the 
relevant documentation.

The problem with changing the default for each compiler version 
means in effect there is no default, and downloading any new 
version means potential breakage that requires extra steps to 
fix, whether you're a beginner or not. We want to eliminate the 
need for extra steps.
Nov 14 2023
next sibling parent Adam Wilson <flyboynw gmail.com> writes:
On Wednesday, 15 November 2023 at 05:27:40 UTC, Mike Parker wrote:

 If someone misses all of that and tries to use tuples without 
 specifying edition N, the compiler should be able to tell them 
 what the problem is, how to solve it (annotate your module 
 declaration with ` edition(N)`), and provide the URL to the 
 relevant documentation.


This is exactly backwards from how most languages today. By 
default you are working with the current edition and you have to 
down-select to earlier editions.

But if we're really enamored of using the crippled version of the 
language by default then it is absolutely imperative that edition 
selection be a command-line option.

Here is how it should work IMO. The build system needs to able to 
specify editions at the package level, but when no package level 
edition is specified, then you assume current. If you need to 
down-select to an older edition then the dependency specifier in 
the project file that I control must set the correct edition. 
This neatly works around the lack of edition specifier in 
abandonware without enforcing crippled-by-default behavior that 
is going to confuse the entire world.
Nov 15 2023
prev sibling parent reply Mike Shah <mshah.475 gmail.com> writes:
On Wednesday, 15 November 2023 at 05:27:40 UTC, Mike Parker wrote:

 On Wednesday, 15 November 2023 at 02:27:42 UTC, Mike Shah wrote:


 [...]


 It's just like any other language feature you have to learn. 
 The documentation will be clearly divided by edition. You'll 
 have one section for the base language (the default edition) 
 and one for each subsequent edition. You can jump in an use the 
 default language without caring about editions. Then when you 
 want to learn more, say sumtypes and tuples from edition N, the 
 documentation, tutorials, and example code you see should make 
 it very clear that you need to specify edition N. And the 
 documentation for edition N will explain all the changes that 
 edition makes.

 [...]


Makes sense -- thanks Mike! Looking forward to learning more!
Nov 15 2023
parent Mike Shah <mshah.475 gmail.com> writes:
On Wednesday, 15 November 2023 at 21:48:04 UTC, Mike Shah wrote:

 On Wednesday, 15 November 2023 at 05:27:40 UTC, Mike Parker 
 wrote:

 On Wednesday, 15 November 2023 at 02:27:42 UTC, Mike Shah 
 wrote:


 [...]


 It's just like any other language feature you have to learn. 
 The documentation will be clearly divided by edition. You'll 
 have one section for the base language (the default edition) 
 and one for each subsequent edition. You can jump in an use 
 the default language without caring about editions. Then when 
 you want to learn more, say sumtypes and tuples from edition 
 N, the documentation, tutorials, and example code you see 
 should make it very clear that you need to specify edition N. 
 And the documentation for edition N will explain all the 
 changes that edition makes.

 [...]


 Makes sense -- thanks Mike! Looking forward to learning more!


I will add that the idea of annotating 'edition' or 'version' is 
something I am use to doing in glsl (e.g. '#version core 410' 
goes at the top of the file), so that is pretty easy.

For others, I'm reading about Rust editions 
(https://doc.rust-lang.org/edition-guide/introduction.html) to 
try to get more education for now. Indeed looks like a win for 
DLang to adopt something similar. For C++ there was an epoch 
proposal 
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html) as well
probably worth skimming for others.
Nov 15 2023
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:






 Átila took on the job of writing the proposal and we set 
 November 1st as the deadline. We've since moved it to 
 mid-December.


I'm going to refrain from chiming in on this any further for now. 
I know what our goals are. I know that we've discussed much of 
what has come up in this thread (e.g., command-line flags vs. 
module attribute).  I don't yet know what the draft proposal will 
look like. I can't say anything definitively until I've seen it.

Our number one goal with editions is to avoid breaking code with 
new compiler releases. Old code, your project or your 
dependencies, should always compile, but still benefit from bug 
fixes in new compiler releases, ideally without any extra steps 
required from you.

Átila has looked into Rust's editions, the proposal for C++ 
epochs, and probably some other stuff. So he's taking inspiration 
from those along with the discussions we've had so far. When the 
draft is ready, we'll publish it for feedback.
Nov 14 2023
prev sibling next sibling parent reply Guillaume Piolat <first.name gmail.com> writes:
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:

 * The default edition, meaning the code you have now, should 
 compile forever.


Should we want that?

I think I really don't like even the concept of Editions. The 
reason for that it stems from an incorrect assumption about how 
software debt works.

Currently the maintenance cost of a library is paid by the 
library maintainers (if any). I'd argue people come to languages 
because of arguably alive libraries, and dead libraries less so.

That an abandoned package build will not help much if it's not 
maintained and say, does not work on Windows arm in 2030. And the 
cost of keeping up with the times is often larger than dealing 
with the language and Phobos changes.

In some economic terms, the dead package did not enough interest 
to pay for its survival.

The burden on the core team would likely be unfair and increasing 
over time, since now the compiler developers must pay the debt of 
abandoned code that should have died, code that they are no owner 
of.

If you want people to stop stumbling upon unmaintained code, then 
either hide more of it (DUB registry could do that), make the DUB 
ratings more reliable and transitive maybe. We have an increasing 
number of high quality library but the dead libraries that 
somehow were registered to DUB accumulate linearly with the 
passing of time (in the same sense that more men have died than 
the number of men that live today).

When alias this breaks the important thing is in my 
not-so-informed opinion "why DlangUI has few maintenance energy" 
not "how can we make it still build".
Nov 21 2023
parent Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 21 November 2023 at 13:13:06 UTC, Guillaume Piolat 
wrote:

 I'd argue people come to languages because of arguably alive 
 libraries, and dead libraries less so.


Yeah, I think this is solving the wrong problem, but even if we 
decide to do it anyway it is very important not to hurt alive 
libs in the name of saving dead libs.

If we increase the cost of new and ongoing things, it will lead 
to more dead things in the future and this would obviously be a 
bad long term result, even if it looks good in the short term.


 When alias this breaks the important thing is in my 
 not-so-informed opinion "why DlangUI has few maintenance 
 energy" not "how can we make it still build".


Well, part of this too is there needs to be a migration path to 
achieve the same (or better) job that you can get it. When the 
cost is small, and ideally if it maintains some compatibility for 
users with old compilers too, it takes less maintenance energy.
Nov 22 2023
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:

 In September 2023, we had one planning session. The major item 
 on the agenda was editions. Other items were a new meeting 
 format, the Bugzilla to GitHub migration, and the future of D.


 The following people attended the session.

 * Walter Bright
 * Ali Çehreli
 * Martin Kinkelin
 * Dennis Korpel
 * Átila Neves
 * Razvan Nitu
 * Mike Parker
 * Robert Schadek


 We had agreed in [the September monthly 
 meeting](https://forum.dlang.org/post/hetwfhikjqwzlvywmyzc forum.dlang.org)
the week before that we need to define what editions will look like before we
start deciding which features should go in any given edition. My goal with this
session was to establish the first point on the timeline: a deadline for the
editions proposal. I also thought it would be a good opportunity for all of us
to clarify what editions are (there were some different ideas about that) and
discuss aspects of the concept we need to consider.


These are excellent progress. I don't wholly agree with the 
strong commitment on backwards compability DLF decided to make, 
but with editions it doesn't matter much. The langauge can remain 
both backwards compatible and develop further at the same time.


 Here are some points that came out of the discussion.

 * Editions are essentially feature sets. Each edition can 
 add/remove/deprecate features.
 * Editions are entirely opt-in and only affect the source you 
 explicitly apply them to, i.e., they are not transitive to 
 dependencies.


Makes sense, but on the other hand we will have a lot of 
questions about templates that are defined in domain of one 
language edition and instantiated in another. It's going to be 
onerous to figure out how those cases will work. Regardless, I'm 
looking forward to this.


 * Editions will most likely be implemented via an attribute on 
 the module declaration. We haven't discussed any details about 
 that, but for now, just imagine something like ` edition(2024) 
 module foo;`.


The syntax isn't critical anyway. That is one small detail that 
won't have to dominate the discussions.


 * Features cannot be opted into individually. When you apply an 
 edition to a module, you get the whole thing.


Makes sense again. Lifts a lot of maintenance burden for 
relatively little user inconvenience. OTOH maybe the existing 
preview/revert flags should stay for the starting version.


 * The default edition, meaning the code you have now, should 
 compile forever.
 * We should have a tool that automates as much as possible the 
 migration of modules to new editions


Isn't this what the `-transition` switches do? Regardless, mostly 
agreed.


About the question of what would be the default edition. Like 
others I tend to think that in cases where neither the module nor 
the compiler invocation has any definitions it should be the 
latest stable edition. Why? Adding `-edition=2023` (or whatever 
the flag for the starting edition would be) to the build script 
of a legacy project is dead simple, and besides needs to be done 
only once, after which the project will always compile. People 
don't hate breakage _that_ much.

The reverse situation, that we'd have to always either use 
`-edition=20xx` or explicilty declare the edition in the module 
header for new code would have the same problems that our  
` system` impure defaults for function attributes. At best, it'd 
annoy people but more likely it'd more or less lead to new code 
being written in the starting edition because we don't remember 
or bother with picking the edition.
Nov 22 2023