Jonathan M Davis wrote: > On Friday, October 26, 2012 10:11:04 Jens Mueller wrote: > > Jacob Carlborg wrote: > > > On 2012-10-25 23:06, Jens Mueller wrote: > > > >I'd prefer the second option. Maybe write first some unittests for > > > >std.uri, if there are none. Then move it. > > > > > > Agree, but we want to minimize the code breakage. > > > > That's what the unittests are for. > > Code breakage that results in compiler errors (i.e. using deprecate) are > > tolerable, I think. Silently code breakage is problematic. > > No. The issue is code breakage in the code of people using Phobos, and if you > change where the module is, you'll break code. Even if we provide a > deprecation path from std.uri to std.net.uri, that still means that people > will have to change their code eventually, meaning that you still have code > breakage (it's just better controlled). Making the change has to be worth > breaking people's code, and making breaking changes to Phobos is becoming > less > and less acceptable. I don't know whether it is or isn't acceptable in this > case.
We should add the cost of fixing to the equation. When code is easy to fix I argue it should always be done. In case of std.uri any import of it needs to be fixed, i.e. the fixing cost is very low. I wish we had some estimate how much code is affected. Can't we release the web page stats or something similar? This way we may estimate how much a module is used. Crawling github is also an option. I don't want to be in a situation where we cannot change things because we have to assume that infinite code is broken. Or we provide an community approved way to have different incompatible versions of a module. Andrei suggested the std.mymodule2 approach at some point. It'll be nice if DConf discusses these organizational problems. They are of strategic importance I firmly believe. Jens