Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote: ## Editions Á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.
Re: DLF September 2023 Planning Update
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 soo 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.
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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 soo 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.
Re: DLF September 2023 Planning Update
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: ## The future of D 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).
Re: First Beta 2.106.0
On Tuesday, 14 November 2023 at 17:44:11 UTC, Steven Schveighoffer wrote: This might be one of the greatest releases of D ever. -Steve I second this.
Re: First Beta 2.106.0
On Thursday, 2 November 2023 at 00:57:23 UTC, Iain Buclaw wrote: Glad to announce the first beta for the 2.106.0 release, ♥ to the 33 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.106.0.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team Filed https://issues.dlang.org/show_bug.cgi?id=24246 for ICE
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote: ## The future of D 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 ~~
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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++.
Re: DLF September 2023 Planning Update
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 :(
Re: DLF September 2023 Planning Update
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
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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
Re: First Beta 2.106.0
On Thursday, 2 November 2023 at 00:57:23 UTC, Iain Buclaw wrote: Glad to announce the first beta for the 2.106.0 release, ♥ to the 33 contributors. Kind of buried in the changelog (because it's just a few issues closed) is a really significant change coming to this version: the much-hated "statement is not reachable" warning is being removed. This might be one of the greatest releases of D ever. -Steve
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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
Re: DLF September 2023 Planning Update
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
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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: ## The future of D 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=PLHTh1InhhwT7gQEuYznhhvAYTel0qzl72=4
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote: ## Editions 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.
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote: ## The future of D Did you see this video from cppnow'23? https://youtu.be/VMYVbA2gg0g?si=fMGbnE0FliLwmYgo It's a good talk about language evolution in general.
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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!
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote: ## Editions We had agreed in [the September monthly meeting](https://forum.dlang.org/post/hetwfhikjqwzlvywm...@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.
DLF September 2023 Planning Update
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. ## Attendees The following people attended the session. * Walter Bright * Ali Çehreli * Martin Kinkelin * Dennis Korpel * Átila Neves * Razvan Nitu * Mike Parker * Robert Schadek ## Editions We had agreed in [the September monthly meeting](https://forum.dlang.org/post/hetwfhikjqwzlvywm...@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. ## Workgroup sessions 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. ## Bugzilla to GitHub migration 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. ## The future of D 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
