std.uni vs std.unicode and beyond?

[Idan Arye]

On Thursday, 23 May 2013 at 00:43:04 UTC, deadalnix wrote:
> On Wednesday, 22 May 2013 at 17:31:17 UTC, Jonathan M Davis 
> wrote:
>> On Tuesday, May 21, 2013 22:32:00 Brad Anderson wrote:
>>> Would the public import people are suggesting not work for
>>> maintaining backward compatibility?
>>> 
>>> Also, couldn't you just do import uni = std.unicode to save on
>>> typing in modules that make use of both std.ascii and 
>>> std.unicode
>>> (that's even less typing than the current requirement to type 
>>> the
>>> fully qualified name which includes std)?
>>
>> Of course we can provide a migration path, but you're still 
>> talking about
>> breaking code, and I don't think that std.uni is a bad enough 
>> name to merit
>> that.
>>
>
> I don't understand why do we need to break code here. It is 
> about introducing a new module.

Doing it while keeping `std.uni` would create a duplication in 
both API and implementation, since `std.unicode` will contain all 
the functionality of `std.uni`. Eventually `std.uni` would have 
to be removed, because if Phobos would keep the old versions 
forever whenever a better version that does the same thing comes 
it will become very cluttered. Java walked that way.

Once the old `std.uni` will be finally removed - code will break.