std.uni vs std.unicode and beyond?

[Steven Schveighoffer]

On Tue, 21 May 2013 12:05:37 -0400, eles <eles at eles.com> wrote:

> On Tuesday, 21 May 2013 at 15:02:25 UTC, Steven Schveighoffer wrote:
>> On Tue, 21 May 2013 08:51:01 -0400, Dmitry Olshansky If the existing  
>> module is std.uni, then let's keep std.uni.
>>
>> std.unicode would be better.  But the code breakage is not worth the  
>> change.
>>
>> As far as restructuring, I don't think it's worth the pain either.
>
> Why so much reluctance? I see it rather as adding a new module to  
> phobos, that supersedes and deprecates another module, which happens to  
> have an undesirable name, too.
>
> If you prefer short names, I would rather go with std.ucode instead of  
> std.uni.

It has nothing to do with the name.  I think unicode is better.  But  
(allegedly) we have existing projects that use std.uni, which would break  
if we renamed.  Even temporary relief such as an alias, deprecation,  
public import, etc would not be completely sufficient.

> Frankly, look at this expansion of phobos on the left of this webpage:
>
> std.typecons
> std.typetuple
> std.uni
> std.uri
> std.utf
> std.uuid
>
> Does that std.uni looks right to you in this context? It is a module  
> about unified name identifiers, isn't? Or specific to unions, those dear  
> data structures from the old C days?

I don't disagree, but is it so bad that it's worth changing the name?   
That's all I'm saying, the bar has to be very high in order to require a  
name change.

In general, changing the name of something without any added benefit  
(aside from the benefit of clarity) needs a very strong case to make that  
change.  You are breaking code for no benefit to someone who doesn't care  
about the name.  As the standard library we have to be super sensitive to  
these cases.

-Steve