Proposal for fixing dchar ranges

[Steven Schveighoffer]

On Mon, 10 Mar 2014 11:11:23 -0400, Dicebot <public at dicebot.lv> wrote:

> On Monday, 10 March 2014 at 15:01:54 UTC, Steven Schveighoffer wrote:
>> That is already broken. What I'm looking to do is remove the cruft and  
>> "WTF" factor of the current state of affairs (an array that's not an  
>> array).
>>
>> Originally (in that long ago proposal) I had proposed to check for and  
>> disallow invalid slicing during runtime. In fact, it could be added if  
>> desired with the type defined by the library.
>
> Broken as if in "you are not supposed to do it user code"? Yes. Broken  
> as in "does the wrong thing" - no. If your index is properly calculated,  
> it is no different from casting to ubyte[] and then slicing. I am pretty  
> sure even Phobos does it here and there.

If the idea to ensure the user cannot slice a code point was added, you  
would still be able to slice via str.representation[a..b], or even  
str.ptr[a..b] if you were so sure of the length you didn't want it to be  
checked ;)

The idea behind the proposal is to make it fully backwards compatible with  
existing code, except for randomly accessing a char, and probably .length.  
Slicing would still work as it does now, but could be adjusted later.

It will break existing code. To fix those breaks, you would need to use  
the char[] array directly via the representation member, or rethink your  
code to be UTF-correct. Basically, instead of pretending an array isn't an  
array, create a new mostly-compatible type that behaves as we want it to  
behave in all circumstances, not just when you use phobos algorithms.

The breaks may be trivial to work around, and might seem annoying.  
However, they may be actual UTF bugs that make your code more correct when  
you fix them.

The biggest problem right now is the lack of the ability to implicitly  
cast to tail-const with a custom struct. We can keep an alias-this link  
for those cases until we can fix that in the compiler.

-Steve