On Mon, 10 Mar 2014 11:11:23 -0400, Dicebot <pub...@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
