DLF September 2023 Planning Update

[Jonathan M Davis]

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