Creeping Bloat in Phobos

[Dmitry Olshansky via Digitalmars-d]

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