Let's talk about deprecations

Seb via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 2 16:27:26 PDT 2017


Hi all,

I think we need to talk about deprecations.
A recent example on [Phobos][#5532] uncovered an ugly truth: many 
people don't seem care about deprecation warnings.

#5532 wanted to remove the symbols scheduled for deprecation - 
most noteworthy here the removal of std.c.
FYI std.c was [deprecated  in September 2014][#2337].
Now, almost three years later, we have Martin's great project 
tester and for the first time we can assess the impact of turning 
deprecations into errors on the D ecosystem. The problem here is 
that the Project-Tester doesn't even get to the state of testing 
external projects, because it already fails on building 
[DUB][dub] and [rdmd][rdmd].
Without being able to see the failing, external projects on the 
Project-Tester I can only guess and with from looking at a few 
projects (e.g. [vibe.d][vibe.d]) it doesn't seem that there's fun 
ahead.

Proposals
---------

I think we should learn from the past. Here are a couple of ideas:

1) Stop making such a fuzz about having a long deprecation 
period. Most people will only care about a deprecation when their 
project doesn't compile anymore. A deprecation period of two 
releases is more than enough for users that care. As seen even 
_eight_ releases don't help! (std.c was deprecated in 2.067)
2) List deprecations in the changelog - users who care read it 
(and as seen there isn't any point to cater or wait for those who 
don't. I stress this point because people notoriously don't add 
their breaking changes to the changelog, which I guess has led to 
frustration & complains in the past and thus resulted in the 
currently cautious attitude against deprecations).
3) Ship a tool like dfmt with new releases that allows easy 
upgrades to new releases
4) Solve the problem automatically: let a bot that crawl _all_ D 
source code on GH and let it submits PRs for trivial deprecations 
(could be based on dfmt or other tools)

Especially with (3) (and optionally (4)) deprecations should 
become a lot less painless and they might again gain the glance 
of "awesome, we are getting rid of old, ugly stuff" instead 
"please don't break anything".

[#5532]: https://github.com/dlang/phobos/pull/5532
[#2337]: https://github.com/dlang/phobos/pull/2337
[dub]: https://github.com/dlang/dub/issues/1183
[tools]: https://github.com/dlang/tools/issues/238
[vibe.d]: https://github.com/rejectedsoftware/vibe.d/issues/1811


More information about the Digitalmars-d mailing list