Uri class and parser

[Jens Mueller]

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