This avoids parsing large files reducing parse time by 30 ms for me
(it took ~70ms to parse tables, now ~40ms).
And move hangul sets to Trie tables as well.
Also saves around 30Kb on "hello world" app.
- Move all tables into functions or structs so that
dmd's multilib will put them into separate archive
objects. This allows the linker to only pick the
tables that are actually used.
- The semantic analysis and object generation only
needs to be done once when building phobos.
Using those overloads becomes a simple link dependency.
- add overloads for most common cases
These have been deprecated for a while, but there was some balking
(primarily from Andrei IIRC) at actually removing them when they were
slated for removal, so they were instead made undocumented and slated
for removal after yet another 6 months or so. So, now that that time has
passed, here's another attempt to actually remove them.
Several deprecated items were listed for removal in August, but it's
looking likely that 2.060 will come out in August, and I'd prefer not to
have them removed for 2.060 given how many items are already in the
changelog, and they're already deprecated, so it'll only affect people
compiling with -d either way. So, I'm changing the ddoc comments to say
September instead of August. They'll be removed in 2.061.
isWhite, isLower, isUpper, toLower, and toUpper now have Ascii in their
name, which matches what std.unit does with its versions of those
functions. Hopefully, it should also reduce bugs due to using the wrong
function between the ASCII and unicode versions by making the difference
more obvious.
I added std.uni.isWhite, fixed the functions so that they returned bool
instead of int, and made a few other tweaks (including reformatting
some of the code which was nigh-on-unreadable with the very odd
indentation choices that had been made with it).
Unfortunately, the change from int to bool was made with the old
functions rather than with new ones, since the names were already good
for those functions. But the code breakage is likely to be minimal,
since the return values were always 1 or 0 and meant to be used as
boolean values. I expect that the code breakage from that will be
far smaller (possibly completely non-existent) than it would have been
to create new functions with different names which returned bool. And
since the names are good as they are, it wouldn't have been nice to
rename them anyway.
