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. ## 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. 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.
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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".
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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!
Re: DLF September 2023 Planning Update
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.
Re: DLF September 2023 Planning Update
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
Re: DLF September 2023 Planning Update
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
Re: DLF September 2023 Planning Update
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"]
Re: DLF September 2023 Planning Update
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
Re: DLF September 2023 Planning Update
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.
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: 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: 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.
