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.
