| |
 | Posted by Jonathan M Davis
in reply to Sergey |  Permalink Reply |
|
Jonathan M Davis 
Posted in reply to Sergey
| 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
|
