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
