29-Sep-2014 00:39, H. S. Teoh via Digitalmars-d пишет:
On Sun, Sep 28, 2014 at 12:57:17PM -0700, Walter Bright via Digitalmars-d wrote:
On 9/28/2014 11:51 AM, bearophile wrote:
Walter Bright:
but do want to stop adding more autodecoding functions like the
proposed std.path.withExtension().
I am not sure that can work. Perhaps you need to create a range2 and
algorithm2 modules, and keep adding some autodecoding functions to
the old modules.
It can work just fine, and I wrote it. The problem is convincing
someone to pull it :-( as the PR was closed and reopened with
autodecoding put back in.
The problem with pulling such PRs is that they introduce a dichotomy
into Phobos. Some functions autodecode, some don't, and from a user's
POV, it's completely arbitrary and random. Which leads to bugs because
people can't possibly remember exactly which functions autodecode and
which don't.
Agreed.
As I've explained many times, very few string algorithms actually need
decoding at all. 'find', for example, does not. Trying to make a
separate universe out of autodecoding algorithms is missing the point.
[...]
Maybe what we need to do, is to change the implementation of
std.algorithm so that it internally uses byCodeUnit for narrow strings
where appropriate. We're already specialcasing Phobos code for narrow
strings anyway, so it wouldn't make things worse by making those special
cases not autodecode.
This doesn't quite solve the issue of composing ranges, since one
composed range returns dchar in .front composed with another range will
have autodecoding built into it. For those cases, perhaps one way to
hack around the present situation is to use Phobos-private enums in the
wrapper ranges (e.g., enum isNarrowStringUnderneath=true; in struct
Filter or something), that ranges downstream can test for, and do the
appropriate bypasses.
We need to either generalize the hack we did for char[] and wchar[] or
start creating a whole new phobos without auto-decoding.
I'm not sure what's best but the latter is more disruptive.
(BTW, before you pick on specific algorithms you might want to actually
look at the code for things like find(), because I remember there were a
couple o' PRs where find() of narrow strings will use (presumably) fast
functions like strstr or strchr, bypassing a foreach loop over an
autodecoding .front.)
Yes, it has fast path.
--
Dmitry Olshansky
