Open zevv opened 5 years ago
cstring
is mapped to JS strings and so len should return what JS's length
returns.
Fair enough, but the behaviour is different for consts and literals then for variables - which might surprise some users, me included.
I can confirm, this is a bug. Only the value of the let expression is correct.
var s1_245005 = makeNimstrLit("\xE2\x99\x9C\xE2\x99\x9E\xE2\x99\x9D\xE2\x99\x9B\xE2\x99\x9A\xE2\x99\x9D\xE2\x99\x9E\xE2\x99\x9C");
rawEcho(makeNimstrLit("lit string "), makeNimstrLit("24"));
rawEcho(makeNimstrLit("lit cstring "), makeNimstrLit("24"));
rawEcho(makeNimstrLit("let string "), cstrToNimstr(((s1_245005 != null ? s1_245005.length : 0))+""));
rawEcho(makeNimstrLit("let cstring "), cstrToNimstr(((toJSStr(s1_245005) != null ? toJSStr(s1_245005).length : 0))+""));
rawEcho(makeNimstrLit("const string "), makeNimstrLit("24"));
rawEcho(makeNimstrLit("const cstring "), makeNimstrLit("24"));
In the other cases Nim thinks in can calculate the size at compile time when in fact it can't. When I tried to resolve this bug, I found out that in semMagic the magic to calculate the length of the cstring is mLengthArray
, not mLengthStr
as it should be, at least by the overloads that are in system.nim
.
What is the semantics of
len()
on unicodecstring
s in javascript? Is the following behaviour expected?native:
Javascript: