Andrej Mitrovic wrote: > select deprecated functionality The problem I have is old code isn't going to change itself to select old functions.
New code, on the other hand, can decide to use new functions since someone is actively writing it. Therefore, it's less painful to opt in to using new code than to select to use old code. > Naming modules "xml.old1" [...] I'd do "xml" and "xml2" rather than "xml.old" since the name is already "xml", and in my view, that's immutable now. This might be a poor man's version control system, but is that bad? It's not uncommon for software (or books or movies...) to have major versions (sequel numbers) in the name. Thanks to D's module namespacing, that name is the only place it'd be too; the code that uses it still looks natural. It's not like they'd have to write parseXML2() all over the place - like is somewhat common in C. Would people find it weird that versions are in the name? Maybe, but again, that's common in a lot of places. Just make sure the Phobos docs point to the newest version by default in the left nav panel so people don't have to hunt for what's newest. Would this naming scheme be a hassle in the source control? I don't think so. 1) If it's a rewrite, it's a different file anyway, even if you gave it the same name; it's not like a patch could apply to both versions. 2) If it's a minor fork, you could surely just apply patches to two branches in git, right? (I don't really know how it works, but I can't imagine it'd be harder than any other branch which I hear git makes easy.) 3) If it's backward compatible, no need to change the number. My only regret is we didn't have the foresight to call it "std.xml1" in the first place.
