std.uni vs std.unicode and beyond?

[Jonathan M Davis]

On Tuesday, May 21, 2013 16:51:01 Dmitry Olshansky wrote:
> The pitch by deadalnix:
> 
> I strongly push into renaming it to std.unicode . As said in the other
> thread : uni can be unicode, but also unique, union, unit, uniform,
> unix, unijambist, whatever.
> 
> When theses pile up in a large library, this is more and more difficult
> to rely on intuition/autocompletion and much more on programmer's
> memory. It mean that it takes longer to learn the whole library.
> 
> 
> My reservations:
> 
> If the chief benefit of renaming is aesthetics then I'd rather pass.
> This kind of knee-jerk changes made on basis of "a good time to try to
> push a better name" just don't belong in design of library/package
> structure. Yeah, I know nobody is going to say "package structure"
> looking at Phobos.
> 
> If we make it a part of restructuring std.* that is long overdue then
> I'm fine as long as package structure is well thought out as a whole.
> Changing it now before adopting a package structure risks the 2nd change
> and another set of arguments for keeping things as is.
> 
> Let's continue discussion here and not in voting thread.

I'm completely against renaming it. It will break code for little benefit. And 
given that std.uni is actually one of the modules that you're _likely_ to have 
to give the full path to (in particular because std.ascii has many of the same 
functions but for ASCII), making it longer would be annoying. Maybe 
std.unicode would be okay if we were creating a brand new module, but std.uni 
already exists. Let's just leave it as-is.

- Jonathan M Davis