Range of chars (narrow string ranges)

[Jonathan M Davis via Digitalmars-d]

On Saturday, 25 April 2015 at 02:04:02 UTC, Steven Schveighoffer 
wrote:
> On 4/24/15 9:02 PM, Walter Bright wrote:
>> On 4/24/2015 4:56 PM, Steven Schveighoffer wrote:
>>> This is pretty easy. We just have to create a string type 
>>> that is
>>> backed by, but
>>> isn't simply an alias to, an array of char.
>>
>> Just shoot me now!
>>
>
> Yeah, that's the reaction I figured I'd get ;) But it doesn't 
> hurt to keep trying since we keep coming back to this over, and 
> over, and over, and over...

Honestly, even if that were the ideal way to go (and I don't 
think that it is), I'd expect that to be even more disruptive 
than trying to rearrange the modules so that front and friends 
don't autodecode for strings.

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.

- Jonathan M Davis