Walter Bright wrote:
Steven Schveighoffer wrote:
On Tue, 20 Jul 2010 14:29:43 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
It's a D1 feature, and has been there since nearly the beginning.
Since when did we care about D1 compatibility?
We care about incompatibilities that silently break code.
const, inout, array appending, final, typeof(string), TLS globals just
to name a few...
If you expect D1 code to compile fine and run on D2, you are deluding
yourself.
No argument there, but we do try to avoid silent breakage.
The worst that happens is that code starts using dchar instead of
char, and either a compiler error occurs and it's fixed simply by doing:
foreach(char c; str)
or it compiles fine because the type is never explicitly stated, and
what's the big deal there? The code just becomes more utf compatible
for free :)
I don't think it's necessarily true that the user really wanted the
decoded character rather than the byte, or even that wanting the decoded
character is more likely to be desired.
Unfortunately it's inconsistent. foreach for ranges operates in terms of
front, empty, popFront - just not for strings.
I avoid foreach in std.algorithm and in generic code.
For my money I'd be okay if foreach (c; str) wouldn't even compile - the
user would be asked to specify the type. But if the implicit type is
allowed, I'm afraid I believe that dchar would be the best choice.
Andrei
