On Tuesday, 28 April 2015 at 21:57:31 UTC, Vladimir Panteleev
wrote:
On Tuesday, 28 April 2015 at 16:48:48 UTC, Jonathan M Davis
wrote:
But of course, we'd want to do the transition in a way that
didn't result in silent behavioral changes that would break
code,
One proposal is to make char and dchar comparisons illegal
(after all, they are comparing different things - an UTF-8 code
unit with a code point, and even though in some cases this
comparison makes sense, in many it doesn't). That would solve
most silent breakages at the expense of more not-so-silent
breakages.
It would, but it doesn't necessarily play nicely with the
promotion rules, and since the character types tend to be treated
as integral types, I suspect that it would be problematic in a
number of cases. I also suspect that it's not something that
Walter would go for given his typical attitude about conversions
(though I don't know). It's definitely an interesting thought,
but I doubt that it would fly.
And if we really wanted to do that, we could create a version
flag that turned of autodecoding and version the changes in
Phobos appropriately to see what we got.
Shameless self-promotion alert: An alternative is a GitHub
fork. You can easily install and try out D forks with Digger,
it's two commands:
digger build master+jmdavis/phobos/noautodecode
digger install
Well, that may very well be what needs to happen as an
experiment, but if we want to actually transition to not having
autodecoding, we need a transition plan in master itself rather
than a fork, and a temporary version would be one way to do that.
After thinking about the situation some over the past few days
though, I think that what we need to do to begin with is to make
it so that as many functions in Phobos as possible don't care
whether they're dealing with ranges of char or dchar so that
they'll work regardless of what front does on strings (either by
simply not using front on strings - or by making it so that the
code will work whether front return char or dchar). And that will
reduce the number of changes that will have to be done in Phobos
via versioning or deprecation or whatever we'd have to do to
actually remove autodecoding. I suspect that it would mean that
very little would have to be versioned or deprecated if/when we
make the switch.
The bigger problem though is probably 3rd party range-based
functions using front with strings or checking rather than Phobos
itself or code using Phobos, since much of that would just work
even if we outright switched front from autodecoding to
non-autodecoding, and most of what wouldn't can be made to work
by making it so that those functions don't care whether they're
dealing with autodecoded strings or not.
- Jonathan M Davis
