std.uni vs std.unicode and beyond?

[nazriel]

On Tuesday, 21 May 2013 at 12:51:05 UTC, 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 would say that new module should be called std.unicode. It is 
way more clear what it does without looking up in docs. For code 
breakage, maybe public import in std.uni + pragma-msg about 
deprecation could lower it a bit?

Restructuring Phobos is really good idea but I would say we wait 
for DIP15 (or any variant) so we can make transition less 
painful. For example std.datetime split could be unnoticeable.