Deprecated Library Functions / Methods

[Adam D. Ruppe]

On Monday, 3 December 2012 at 02:04:01 UTC, Jonathan M Davis 
wrote:
> It's messy and ugly to leave dead code around in a library.

It's messier and uglier to break everyone else's code because a 
small group of people with phobos access decided to unilaterally 
change things.

There's an easy solution to this btw, a versioning scheme in 
module names:

---
module std.xml;
pragma(msg, "std.xml sux. if you don't wanna break code import 
std.xml.1 instead. if you wanna use the rox version the latest is 
std.xml.2");
public import std.xml.1; /* legacy support */
/* if this wasn't an already existing module, we would static 
assert(0) instead of pragma msg. NEVER use a naked import like 
this since it is guaranteed to break. At least by picking a major 
version, you have a fighting chance of unmodified code still 
working out of the box down the line */
---
module std.xml.1;
public import std.xml.1.4;
---
module std.xml.1.4; // random number btw
/* current std.xml */
---
module std.xml.2;
public import std.xml.2.0;
---
module std.xml.2.0;
/* a brand new std.xml */
---

The package as module thing is some DIP magic but we could do 
without by naming it std.xml_2 and std.xml_2_0 or whatever too.


Anyway the rules are:

1) Less specific numbers simply forward you to the next specific 
module, just like symlinks do on the ideal unix .so library. All 
modules from here on out have a version number, but current 
modules are grandfathered in, albeit perhaps deprecated.

2) The most specific thing includes the actual code

3) once a file has been released, it is immutable. ALL releases 
with changes bump up the version number accordingly and go to a 
new file. I'm sure we can do some kind of git tagging script or 
whatever to make this simple.

4) Users import a particular major version normally, or may 
import a minor version if they really want to get super specific.


Boom, code never breaks and we have prettiness.