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