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