Creeping Bloat in Phobos

[Peter Alexander via Digitalmars-d]

On Sunday, 28 September 2014 at 00:13:59 UTC, Andrei Alexandrescu 
wrote:
> On 9/27/14, 3:40 PM, H. S. Teoh via Digitalmars-d wrote:
>> If we can get Andrei on board, I'm all for killing off 
>> autodecoding.
>
> That's rather vague; it's unclear what would replace it. -- 
> Andrei

No autodecoding ;-)

Specifically:

1. ref T front(T[] r) always returns r[0]
2. popFront(ref T[] r) always does { ++r.ptr; --r.length; }
3. Narrow string will be hasLength, hasSlicing, 
isRandomAccessRange (i.e. they are just like any other array).

Also:

4. Disallow implicit conversions, comparisons, or any operation 
among char, wchar, dchar. This makes things like "foo".find('π') 
compile time errors (or better, errors until we specialize to it 
to do "foo".find("π"), as it should)
5. Provide byCodePoint for narrow strings (although I suspect 
this will be rarely used).

The argument is as follows:
* First, this is a hell of a lot simpler for the implementation.
* People rarely ever search for single, non-ASCII characters in 
strings, and #4 makes it an error if they do (until we specialize 
to make it work).
* Searching, comparison, joining, and splitting functions will be 
fast and correct by default.

One possible counter argument is that this makes it easier to 
corrupt strings (since you could, e.g. insert a substring into 
the middle of a multi-byte code point). To that I say that it's 
unlikely. When inserting into a string, you're either doing it at 
the front or back (which is safe), or to some point that you've 
found by some other means (e.g. using find). I can't imagine a 
scenario where you could find a point in the middle of a string, 
that is in the middle of a code point.

Of course, I'd probably say this change isn't practical right 
now, but this is how I'd do things if I were to start over.