Range of chars (narrow string ranges)

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 28 April 2015 at 21:57:31 UTC, Vladimir Panteleev 
wrote:
> On Tuesday, 28 April 2015 at 16:48:48 UTC, Jonathan M Davis 
> wrote:
>> But of course, we'd want to do the transition in a way that 
>> didn't result in silent behavioral changes that would break 
>> code,
>
> One proposal is to make char and dchar comparisons illegal 
> (after all, they are comparing different things - an UTF-8 code 
> unit with a code point, and even though in some cases this 
> comparison makes sense, in many it doesn't). That would solve 
> most silent breakages at the expense of more not-so-silent 
> breakages.

It would, but it doesn't necessarily play nicely with the 
promotion rules, and since the character types tend to be treated 
as integral types, I suspect that it would be problematic in a 
number of cases. I also suspect that it's not something that 
Walter would go for given his typical attitude about conversions 
(though I don't know). It's definitely an interesting thought, 
but I doubt that it would fly.

>> And if we really wanted to do that, we could create a version 
>> flag that turned of autodecoding and version the changes in 
>> Phobos appropriately to see what we got.
>
> Shameless self-promotion alert: An alternative is a GitHub 
> fork. You can easily install and try out D forks with Digger, 
> it's two commands:
>
> digger build master+jmdavis/phobos/noautodecode
> digger install

Well, that may very well be what needs to happen as an 
experiment, but if we want to actually transition to not having 
autodecoding, we need a transition plan in master itself rather 
than a fork, and a temporary version would be one way to do that.

After thinking about the situation some over the past few days 
though, I think that what we need to do to begin with is to make 
it so that as many functions in Phobos as possible don't care 
whether they're dealing with ranges of char or dchar so that 
they'll work regardless of what front does on strings (either by 
simply not using front on strings - or by making it so that the 
code will work whether front return char or dchar). And that will 
reduce the number of changes that will have to be done in Phobos 
via versioning or deprecation or whatever we'd have to do to 
actually remove autodecoding. I suspect that it would mean that 
very little would have to be versioned or deprecated if/when we 
make the switch.

The bigger problem though is probably 3rd party range-based 
functions using front with strings or checking rather than Phobos 
itself or code using Phobos, since much of that would just work 
even if we outright switched front from autodecoding to 
non-autodecoding, and most of what wouldn't can be made to work 
by making it so that those functions don't care whether they're 
dealing with autodecoded strings or not.

- Jonathan M Davis