You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some reason cstring can implicitly convert to pointer but not ptr char, and that's true for all backends. Converting to pointer in JS though is broken because of the following:
Nim treats the cstring like it's a pointer already and tries to copy instead of converting. This will break, ["a", "b"] is not a valid pointer.
Expected Output
meaning expected codegen:
varx_622003="abcd";vary_622004=[x_622003,0];
Additional Information
["abcd", 0] being a valid pointer is another question, since JS cstrings are immutable, but this already happens when used like this:
var x =cstring"abcd"let y =addr x[0]
discard y
y in this case is ["abcd", 0]. A good solution to this would be to make cstrings in JS unsafe addresses like let variables, but the same would have to apply to the implicit pointer conversion.
$ nim -v
Nim Compiler Version 1.2.0
The text was updated successfully, but these errors were encountered:
This is nasty, and there are other issues with mapping cstring to js strings.
I feel Uint8Array is a better fit to map cstring. Considerations of backward compatibility aside, I think we should explore this option. I'm eying at something like this:
introduce nim type jstring that maps to js' immutable strings; nim type system forbids mutations, eg does not provide proc []=(a: jstring, index: int)
map nim type cstring to Uint8Array. It has very similar semantics to cstring, including mutability and ability to take views over some data
example
proc`$`(a: cstring): jstring =
{.emit: "`result` = new TextDecoder().decode(`a`);".}
proctoCstring(a: jstring): cstring=
{.emit: "`result` = new TextEncoder().encode(`a`);".}
For some reason
cstring
can implicitly convert topointer
but notptr char
, and that's true for all backends. Converting topointer
in JS though is broken because of the following:Example
Current Output
Generated codegen:
Nim treats the cstring like it's a pointer already and tries to copy instead of converting. This will break,
["a", "b"]
is not a valid pointer.Expected Output
meaning expected codegen:
Additional Information
["abcd", 0]
being a valid pointer is another question, since JS cstrings are immutable, but this already happens when used like this:y
in this case is["abcd", 0]
. A good solution to this would be to makecstring
s in JS unsafe addresses likelet
variables, but the same would have to apply to the implicit pointer conversion.The text was updated successfully, but these errors were encountered: