On 9/28/2014 1:38 PM, bearophile wrote:
Walter Bright:
It can work just fine, and I wrote it. The problem is convincing someone to
pull it :-( as the PR was closed and reopened with autodecoding put back in.
Perhaps you need a range2 and algorithm2 modules. Introducing your changes in a
sneaky way may not produce well working and predictable user code.
I'm not suggesting sneaky ways. setExt() was a NEW function.
I know that you care about performance - you post about it often. I would
expect that unnecessary and pervasive decoding would be of concern to you.
I care first of all about program correctness (that's why I proposed unusual
things like optional strong typing for built-in array indexes, or I proposed the
"enum preconditions").
Ok, but you implied at one point that you were not aware of which parts of your
string code decoded and which did not. That's not consistent with being very
careful about correctness.
Note that autodecode does not always happen - it doesn't happen for ranges of
chars. It's very hard to look at piece of code and tell if autodecode is going
to happen or not.
Secondly I care for performance in the functions or parts
of code where performance is needed. There are plenty of code where performance
is not the most important thing. That's why I have tons of range-base code. In
such large parts of code having short, correct, nice looking code that looks
correct is more important. Please don't assume I am simple minded :-)
It's very hard to disable the autodecode when it is not needed, though the new
.byCodeUnit has made that much easier.
