Formal Review of std.uni

[Jonathan M Davis]

On Tuesday, April 30, 2013 03:02:17 Dmitry Olshansky wrote:
> 29-Apr-2013 22:50, Jonathan M Davis пишет:
> > On Monday, April 29, 2013 22:13:09 Dmitry Olshansky wrote:
> >> Technically these should be in std.string and are there but incorrect.
> > 
> > Then fix them there.
> 
> I think it will take a certain amount of leaked implementation details
> to get it done at least half-decently. In particular to re-use the same
> case-folding table as for case-insensitive matching.
> 
> Would be a strategic mistake IMHO to spread the internals across 2 modules.
> 
> Then std.string could provide a public alias(es) as it imports std.uni
> anyway?
> 
> Going further if we are to preserve the status quo then std.uni will
> declare them as package to not advertise their new location.

An alias would be one option. The primary issue I see is that the general 
design of the modules has been that std.ascii and std.uni operate on 
individual characters and not strings, whereas std.string operates on strings 
(generally going with the unicode versions of things when there's a choice 
rather than the ASCII ones). And having overloads in std.uni which operate on 
strings doesn't follow that organizational model. Usually, std.string has 
called the std.uni functions to do what it's needed, and no implementation 
details have been leaked. I haven't looked at what you've done with std.uni 
yet, so I don't know how well that would work. But toLower and toUpper are far 
from them only functions which would be affected by something like this (icmp 
would be another obvious one).

But even if we decided to reorganize where some functionality or functions 
live, we shouldn't have std.uni replacing std.string functions while leaving 
the old functions in std.string. So, worst case, aliases should be used, but 
if at all reasonable, I'd prefer to keep the module organizational structure 
that we've had with regards to how characters and string functionality is 
organized.

- Jonathan M Davis