[Issue 7515] The new std.string.translate is slow for ASCII text

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=7515



--- Comment #3 from Jonathan M Davis <jmdavisProg at gmx.com> 2012-03-06 15:27:13 PST ---
> 1) If they don't already say it, then I suggest to add in the ddoc of the
> functions that the translation arrays have a length 128. This for both old D
> programmers and Python programmers.

I don't know. It seems to me that that's an implementation detail. makeTrans
doesn't even return a static array. It returns a dynamic one. So, as long as
the array passed to translate comes from makeTrans (as it should), it's
complete non-issue. If anything, I'd argue for creating a struct (e.g.
TransTable) which just held the dynamic array without giving access to it so
that no one _can_ screw with it (since screwing with it is just going to break
code).

It seems to me that the only reason that makeTrans exists in the first place
rather than just putting it in translate is so that you can reuse the
translation table. No one should be messing with it or passing anything else to
that version of translate. So, why does the length of the array matter to the
user of makeTrans or translate?

And actually, I'm _really_ tempted to just go and change it so that it returns
a struct which you can't mess with and is only created by makeTrans. That
completely resolves any possible issues caused by someone passing the wrong
array to translate.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------