Warning: implicit conversion to 'cstring' from a non-const location: ...; this will become a compile time error in the future
(I'm using Nim 1.6.8 and this warning may have been introduced for some time, maybe even a long time...)
Given that Javascript strings have different semantic than "C" strings, i.e., they are garbage-collected, it doesn't seem harmful to have this implicit conversion and I'm wondering if there should be an exception for the JS backend?
The issue with JS is that most DOM/FFI APIs use cstring and so it forces the user to add .cstring annotations in a lot of places, most of which can't be const, which becomes counter-productive and ineffective in preventing any sort of real defect (AFAIU).
Thoughts?
Even if it's not unsafe, it could affect performance to convert Nim strings to JS strings, and it's better if this is explicitly shown.
In general to prevent too many cstring conversions, you can try to work directly on cstring. Sometimes you may need to importjs some JS string methods to make it work efficiently though. In the future we might have a separate type like JsString so that this is easier.