On 2012-10-28 12:39, Jonathan M Davis wrote:
I don't know everything that he's basing it on, but we've definitely had complaints in this newsgroup in the past over breaking changes (and it wouldn't surprise me if the folks in this newsgroup are more willing to put up with breaking changes than most D users). Even changes which are very popular can generate complaints about the code breakage that they cause. When the library is younger, it's not such a big deal, but as it matures, it becomes a very big deal. And at this point, we seem to be mature enough that we're moving away from the stage where it's okay to break stuff without a very good reason. Certainly, if we don't reach there soon, then it's going to be much harder for D to catch on. We'd like to get to the point that we don't break anything ever (or at least don't break anything without a major version change of some kind).
I think we should be able to break code when there's a good reason for it. The RailsConf 2012 had a great talk called "Progress". I think it's really worth seeing:
http://www.youtube.com/watch?v=VOFTop3AMZ8
In this case, if moving std.curl to std.net.curl isn't deemed worth the breakage that it would cause (and I'd be very suprised if Walter thought that it was), then we'd probably just keep std.curl and not move it at all. And while reorganizing some modules might be desirable, it really doesn't buy us much. I'd strongly argue that if it's not worth putting a module through the deprecation process in order to rename it, then it shouldn't be renamed at all. Having both std.curl and std.net.curl around permanently (even if one is basically an alias of the other), just seems like a bad idea to me. It creates clutter in the library. Best case, we could rename std.curl to std.net.curl, leaving std.curl empty save for the fact that it publicly imports std.net.curl, undocument std.curl completely, and then leave it around as undocumented, but that still creates clutter. It's just less visible.
That's way we need to stop this madness of putting all modules in the "std" package. BTW, this should have happened five years ago.
Aside from there being two modules as part of deprecating one and getting code to use the new one (which we really do want to stop doing), then I would only expect us to end up with two modules if we completely revamped a module but didn't want to break code using the old version (e.g. std.xml - > std.xml2). - Jonathan m Davis
-- /Jacob Carlborg
