This is why I don't use D.

Jonathan M Davis newsgroup.d at jmdavisprog.com
Wed Sep 5 14:45:25 UTC 2018


On Wednesday, September 5, 2018 8:18:03 AM MDT SashaGreat via Digitalmars-d 
wrote:
> On Wednesday, 5 September 2018 at 13:27:48 UTC, Steven
>
> Schveighoffer wrote:
> > 3ddemo has one commit. In February 2016. I think it would be an
> > amazing feat indeed if a project with one version builds for
> > more than 2 years in any language.
> >
> > I built it successfully with DMD 2.076 (I just picked a random
> > old version). So it's still usable, you just have to know what
> > version of the compiler to use. I'd say it would be nice to
> > record which version it builds with in some way on
> > code.dlang.org.
>
> I think the first post is an overreaction, but now I'd like to
> know what is the correct line of thinking in the community:
>
> It's normal that it's not working newer versions?
>
> I'm not being sarcastic, because if breakage is for a good reason
> or in pursuit of a better language I wouldn't mind so much.
>
> But I'd to know if breakage is considerate "normal" or
> "shouldn't" happen in any way, like for example in Linux user
> space (Even it's not 100%) or C++ world.
>
> I'm telling this because I'm stuck with an older DMD version:
> 2.062, because the newer versions doesn't compiles my project.
>
> S.

Really, the expectation is that you're going to use a version of dmd/ldc/gdc
that is at least close to current. It may make sense to stick to a
particular compiler version for a while, but the longer you go without
updating, the more likely it is that your code will break. 2.062 is
positively ancient at this point, and depending on what your code does, it
could be rather interesting to update it. I'd suggest that you try to move
up through the compiler versions a few at a time rather than jumping
straight to the latest, since that way, if you're using any symbols or
features that were removed, you'll benefit from deprecation messages along
the way, and in general, the changes required to keep code working when
jumping only a few compiler releases are minimal (though it obviously
depends on the code).

We do generally want to keep code compiling long term if possible, but if a
change is required to improve the language or standard library, then we'll
often make it. Such changes are done via the deprecation process so that
they don't immediately break code, but the deprecation process for Phobos is
generally about two years (it's less consistent with dmd, though if
anything, it's generally longer rather than shorter). So, if you go that
long without making sure that you're code compiles with the current
compiler, then you could easily have code breakage. You may very well not
end up being affected by any deprecations for years, depending on what
you're doing, but the longer you go without moving to a newer compiler, the
more likely you are to have problems. And while we try not to break code
without going through the deprecation process, regressions do sometimes get
in, and sometimes, fixing a bug means breaking existing code (especially if
code depends on the buggy behavior for one reason or another). The kind of
changes that we generally avoid are those where we can't provide a gradual
transition (e.g. we'd love to get rid of auto-decoding, but no one has yet
come up with a way to do it that wouldn't immediately break tons of code, so
we haven't gotten rid of it).

If you're expecting to be able to write D code, not touch it for years, and
then have it continue to work with the newest compiler, then you're going to
be very disappointed. However, if you at least make sure that your code
works with the current compiler every few releases, then it usually
shouldn't take much effort to keep it working. Over time, we've gotten
pickier about what we're willing to break (e.g. we won't usually change
symbols names just because the current name isn't as good as we'd like,
whereas 5+ years ago, we were a lot more willing to change names in order to
improve Phobos), and most stuff does stay the same, but don't expect that
everything is set in stone. Changes should usually be gradual enough to
avoid immediately breaking code, but they do happen. So, if you want your D
code to continue to work over time, I would encourage you to make sure that
it works with the current compiler at least yearly.

- Jonathan M Davis





More information about the Digitalmars-d mailing list