Jonathan M Davis wrote: > On Friday, October 26, 2012 11:27:40 Jens Mueller wrote: > > Is it okay to have both modules and only state in std.uri's > > documentation that you shouldn't use it anymore (similar to std.xml)? > > This would break no code. > > If we were to move it, we'd temporarily leave a near-empty std.uri which > publicly imported std.net.uri. At some later date, we'd then deprecate it, > and > then later actually remove it. There's a definite cost to leaving such a > module > around long term, because then you code floating around using both std.uri > and > std.net.uri. We might try something like removing it from the documentation > instead of deprecating it (or at least delay that deprecation for a while), > but then you'd have code silently using it without its developers knowing > that > they needed to change anything. > > It can certainly be done, and there are things that can be done to mitigate > how quickly code is broken, but if you move it, code _will_ be broken at some > point, and if you leave what basically amounts to an alias around to it long > term, there's a definite cost to that as well. > > Personally, I wouldn't be against putting std.uri through the deprecation > path > and move it to std.net.uri, but I'm also almost certainly the person who has > broken the most of Phobos' API in an effort to make it consistent (something > which Walter has never been happy with). So, I'm not really in a position to > approve such a change. At this point, I think that something like that pretty > much has to go through Andrei.
It's a difficult compromise that has to be found. That's why I also want more data to make a decision. But I'm actually more towards breaking code if it makes sense. Ideally we should be able to measure the impact that a breaking change will have. deprecate allows something like this. I.e. deprecate it and if you get lots of complaints rethink whether it is worth it. E.g. setAssertHandler used to be deprecated. Now it is undeprecated. Unfortunately there are no portable solutions. The only thing I found is symbol versioning. But this is only supported by GNU ld. These strategic issues need to be solved. Jens
