Why the hell doesn't foreach decode strings
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Fri Oct 21 14:31:48 PDT 2011
On 10/21/11 1:38 PM, Walter Bright wrote:
> On 10/21/2011 2:51 AM, Martin Nowak wrote:
>> You have a good point here. I would have immediately thrown out the
>> loop AFTER
>> profiling.
>> What hits me here is that I had an incorrect program with built-in
>> unicode aware
>> strings.
>> This is counterintuitive to correct unicode handling throughout the
>> std library,
>> and even more to the complementary operation of appending any char
>> type to strings.
>
> I understand the issue, but I don't think it's resolvable.
It is resolvable, just not without breaking compatibility. Latching on
the notion that a problem is unsolvable is highly nocive because it sets
up the mind for failing to not only look for solutions, but also to see
and understand them when they're in the open.
I said this a number of times, and I repeat: if we had the luxury of
doing it over again, I'd disable random access and .length for char[],
wchar[], and their qualified versions. For those types I would add a
property .rep that yields respectively ubyte[], ushort[], and the
appropriately-qualified variants.
This would shed the remaining awkwardnesses from a generally very
elegant approach to string handling.
The loop issue would be trivial to solve. foreach (x; s) would iterate
one dchar at a time, whereas foreach (x; s.rep) would iterate one ubyte
or ushort at a time. There would be the ability to iterate foreach (ref
x; s.rep) but not foreach (ref x; s).
Andrei
More information about the Digitalmars-d
mailing list