On Saturday, 25 April 2015 at 02:04:02 UTC, Steven Schveighoffer
wrote:
On 4/24/15 9:02 PM, Walter Bright wrote:
On 4/24/2015 4:56 PM, Steven Schveighoffer wrote:
This is pretty easy. We just have to create a string type
that is
backed by, but
isn't simply an alias to, an array of char.
Just shoot me now!
Yeah, that's the reaction I figured I'd get ;) But it doesn't
hurt to keep trying since we keep coming back to this over, and
over, and over, and over...
Honestly, even if that were the ideal way to go (and I don't
think that it is), I'd expect that to be even more disruptive
than trying to rearrange the modules so that front and friends
don't autodecode for strings.
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.
- Jonathan M Davis
