Creeping Bloat in Phobos

[Kagamin via Digitalmars-d]

On Sunday, 28 September 2014 at 12:09:50 UTC, Andrei Alexandrescu 
wrote:
> On 9/27/14, 4:31 PM, H. S. Teoh via Digitalmars-d wrote:
>> On Sat, Sep 27, 2014 at 11:00:16PM +0000, bearophile via 
>> Digitalmars-d wrote:
>>> H. S. Teoh:
>>>
>>>> If we can get Andrei on board, I'm all for killing off 
>>>> autodecoding.
>>>
>>> Killing auto-decoding for std.algorithm functions will break 
>>> most of
>>> my D2 code... perhaps we can do that in a D3 language.
>> [...]
>>
>> Well, obviously it's not going to be done in a careless, 
>> drastic way!
>
> Stuff that's missing:
>
> * Reasonable effort to improve performance of auto-decoding;
>
> * A study of the matter revealing either new artifacts and 
> idioms, or the insufficiency of such;
>
> * An assessment of the impact on compilability of existing code
>
> * An assessment of the impact on correctness of existing code 
> (that compiles and runs in both cases)
>
> * An assessment of the improvement in speed of eliminating 
> auto-decoding
>
> I think there's a very strong need for this stuff, because 
> claims that current alternatives to selectively avoid 
> auto-decoding use the throwing of hands (and occasional chairs 
> out windows) without any real investigation into how library 
> artifacts may help. This approach to justifying risky moves is 
> frustratingly unprincipled.

As far as I see, backward compatibility is fairly easy.
Extract autodecoding modules into `autodecoding` dub package and 
clean up phobos modules into non-decoding behavior. The phobos 
code will be simplified: it will deal with ranges as is without 
specialization, the `autodecoding` dub package will be simple: 
just wraps strings into dchar range and invokes non-decoding 
function from phobos, preserves current module interface to keep 
legacy D code working.
Run dfix on your sources, it will replace `import std.algorithm` 
with `import autodecoding.algorithm` - then the code should work.
What do you think? Worth a DIP?