On Monday, 27 April 2015 at 17:49:04 UTC, Jonathan M Davis wrote:
On Monday, 27 April 2015 at 17:01:03 UTC, H. S. Teoh wrote:
On Sat, Apr 25, 2015 at 02:27:45AM +0000, Jonathan M Davis via
Digitalmars-d wrote:
[...]
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.
[...]
I would vote for this approach, if we ever decide to get rid of
autodecoding. I'm OK with either option -- get rid of
autodecoding, or
keep it and use it consistently. What I am *not* OK with is
the present,
and growing, schizophrenic mixture of autodecoding and
non-autodecoding
string functions in Phobos. This inconsistency is going to
come back to
bite us later.
I expect that the two biggest problems causing the current
situation are
1. Andrei and Walter don't seem to agree on the issue (Andrei
seems to think that it's not a big deal to leave in the
autodecoding).
2. While most of the core devs want to get rid of the
autodecoding, it's a big enough change that we're afraid to do
it and/or aren't sure of how we could do it without being too
disruptive.
So, Walter has been pushing the schizophrenic approach in an
effort to work around the problem. If the core devs could agree
on an approach to removing autodecoding that wasn't too
disruptive and somehow get Andrei to go along with it, then we
could do that and fix the problem, but otherwise, Walter is
just going to push for the schizophrenic approach, because it
at least partially fixes the autodecoding problem, and enough
of the core devs want to ditch the autodecoding that at least
some of those changes are likely to make it in.
Honestly, I think that we need to figure out what the best
options are for killing autodecoding and then figure out how to
convince Andrei of it, but I haven't a clue how to convince
Andrei unless maybe a solution which isn't very disruptive can
be found, but it seems like every time the issue comes up, he
gets annoyed that we're spending time on something unimportant.
I do think that this limbo needs to stop though, and I think
that it's clear that while autodecoding seemed like a good idea
at first (especially if code points really were full characters
instead of having to worry about graphemes), ultimately,
autodecoding is a mistake.
- Jonathan M Davis
Would it be much work to show have example code or even an
experimental module that gets rid of auto-decoding, so we could
see what would be affected in general and how actual code we have
would be affected by it?
The topic keeps coming up again and again, and while I'm in favor
of anything that enhances performance, I'm afraid of having to
refactor large chunks of my code. However, this fear may be
unfounded, but I would need some examples to visualize the
problem.