Fix Phobos dependencies on autodecoding

a11e99z black80 at bk.ru
Tue Aug 13 08:52:58 UTC 2019


On Tuesday, 13 August 2019 at 07:51:23 UTC, Alexandru Ermicioi 
wrote:
> On Tuesday, 13 August 2019 at 07:31:28 UTC, a11e99z wrote:
>> On Tuesday, 13 August 2019 at 07:08:03 UTC, Walter Bright
>
> One of the reasons is that it adds unnecessary complexity for 
> templated code that is working with ranges. Check function 
> prototypes for some algorithms found in std.algorithm package, 
> you're bound to find special treatment for autodecoding 
> strings. It also messes up user expectation when suddenly 
> applying a range function on a string instead of front char 
> you're getting dchar.
>

imo this is a contrived problem.
string contains chars, not in meaning "char" as type but runes or 
codepoints.
and world is not perfect so chars/runes are stored as utf8 
codepoints.

in world where "char" is alias for "byte"/"ubyte" such vision was 
a problem:
   is this buffer string(seq of chars) or just raw bytes? how it 
should be enumerated?
but we have better world with different bytes and chars.

probably better was naming for "char" as "utf8cp"/orSomething 
(don't mix with C/C++ type)
and when u/anybody see string from that point everything falls 
into place.

I don't see problem that str.front returns codepoint from 
0..0x10ffff and when str.length returns 21 and str.count=12. but 
somebody see problem here, so again this is a contrived problem. 
and for now this vision problem will recreate/recheck tons of 
code.
I thought that WB don't want change code peremptorily. Should be 
BIG problem when he does.


More information about the Digitalmars-d mailing list