Creeping Bloat in Phobos

[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.


> 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.

(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.)


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide',
doesn't seem to remove the bugs on my system! -- Mike Dresser