Range of chars (narrow string ranges)

[Chris via Digitalmars-d]

On Monday, 27 April 2015 at 17:49:04 UTC, Jonathan M Davis wrote:
> On Monday, 27 April 2015 at 17:01:03 UTC, H. S. Teoh wrote:
>> On Sat, Apr 25, 2015 at 02:27:45AM +0000, Jonathan M Davis via 
>> Digitalmars-d wrote:
>> [...]
>>> I suppose that a related alternative would be to change it so 
>>> that
>>> strings aren't considered ranges anymore (at least 
>>> temporarily), and
>>> force folks to use stuff like byChar or byDChar (or whatever 
>>> those
>>> functions are) whenever they use strings as ranges. And 
>>> actually, that
>>> _would_ allow us to get rid of the autodecoding without 
>>> rearranging
>>> modules. Later, we could change them to being ranges of their 
>>> actual
>>> element types, or we could just force folks to be explicit 
>>> forever in
>>> an effort to make the Unicode issues clear, if we thought 
>>> that that
>>> were better (though it would probably better to just change 
>>> front and
>>> friends later to work with strings again but not autodecode). 
>>> And if
>>> an algorithm would work with either autodecoding or without 
>>> it, then
>>> maybe it could be special cased to accept strings as ranges, 
>>> only
>>> forcing it in the cases where it the behavior of the 
>>> algorithm would
>>> change based on whether autodecoding were used or not.
>>> 
>>> Hmmm. I'm not sure what all of the repercussions of such an 
>>> approach
>>> would be, but the more I think about it, the more tempting it 
>>> seems to
>>> me.
>> [...]
>>
>> I would vote for this approach, if we ever decide to get rid of
>> autodecoding. I'm OK with either option -- get rid of 
>> autodecoding, or
>> keep it and use it consistently. What I am *not* OK with is 
>> the present,
>> and growing, schizophrenic mixture of autodecoding and 
>> non-autodecoding
>> string functions in Phobos. This inconsistency is going to 
>> come back to
>> bite us later.
>
> I expect that the two biggest problems causing the current 
> situation are
>
> 1. Andrei and Walter don't seem to agree on the issue (Andrei 
> seems to think that it's not a big deal to leave in the 
> autodecoding).
>
> 2. While most of the core devs want to get rid of the 
> autodecoding, it's a big enough change that we're afraid to do 
> it and/or aren't sure of how we could do it without being too 
> disruptive.
>
> So, Walter has been pushing the schizophrenic approach in an 
> effort to work around the problem. If the core devs could agree 
> on an approach to removing autodecoding that wasn't too 
> disruptive and somehow get Andrei to go along with it, then we 
> could do that and fix the problem, but otherwise, Walter is 
> just going to push for the schizophrenic approach, because it 
> at least partially fixes the autodecoding problem, and enough 
> of the core devs want to ditch the autodecoding that at least 
> some of those changes are likely to make it in.
>
> Honestly, I think that we need to figure out what the best 
> options are for killing autodecoding and then figure out how to 
> convince Andrei of it, but I haven't a clue how to convince 
> Andrei unless maybe a solution which isn't very disruptive can 
> be found, but it seems like every time the issue comes up, he 
> gets annoyed that we're spending time on something unimportant. 
> I do think that this limbo needs to stop though, and I think 
> that it's clear that while autodecoding seemed like a good idea 
> at first (especially if code points really were full characters 
> instead of having to worry about graphemes), ultimately, 
> autodecoding is a mistake.
>
> - Jonathan M Davis

Would it be much work to show have example code or even an 
experimental module that gets rid of auto-decoding, so we could 
see what would be affected in general and how actual code we have 
would be affected by it?

The topic keeps coming up again and again, and while I'm in favor 
of anything that enhances performance, I'm afraid of having to 
refactor large chunks of my code. However, this fear may be 
unfounded, but I would need some examples to visualize the 
problem.