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.
