On Tue, 21 May 2013 12:05:37 -0400, eles <[email protected]> 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
