On Tuesday, 14 November 2023 at 18:24:09 UTC, Paolo Invernizzi wrote:

+1 to Steven’s approach

Idk why DLF don’t like KISS approach :(

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

You are describing my first attempt to attempt to use "modern C++" features. Certainly didn't want me to learn any more C++.

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

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.

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

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.

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

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 ~~

On Tuesday, 14 November 2023 at 21:13:34 UTC, monkyyy wrote:

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! :)

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

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

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.

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

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.

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.

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.

On Wednesday, 15 November 2023 at 02:38:38 UTC, Adam D Ruppe wrote:

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.