I recently found out, that cstring is not according to the documentation just for interfacing the C backend, but also for javascript. With the result that cstring now means compatible string.
I was about to update the documentation and create a pull request, so this behavior is documented properly. But when I wrote it, I realized that I did not like this all that much. This was probably already discussed, but I would like to ask, if you are really sure for this design decision, and if yes I will create my pull request.
The cstring type was in perfect harmony with the family of other c types like cschar, cshort, cint, csize, clonglong, cfloat, cdouble, clongdouble, cuchar, ... and now this consistency is broken, because when cstring now becomes compatible string, does cint now also become compatible int? Especially because javascript does not have a native int representation, it only knows 64bit floating point numbers. And then there is also the case, where nim compiles to C, but calls into a javascrip interpreter, how should this handle then be called?
I think a good solution to a problem like this is already implemented in the programming language GO. Go can call c functions, but the c compatible datatypes are not available by default. They have to be imported first from the module C and then they are available as C.int C.float etc. C strings are just pointers to char, and for conversion there are functions provided C.CString C.GoString C.GoStringN. It's not all that different than what nim does, the only difference is, that all c types need to be imported first to be used. The Javascript backend of Go has it's own package to interact with javascript here. Everything is split more explicitly, and there is no system wide hybrid type that has to be compatible with whatever the backend is.
But I also see that cint is used a lot everywhere in a lot of packages, and that it is a bit late to say now, it has to be explicitly imported to be used, it would beake a lot of code. So I would like to hear your opinion about it.
If I would think Go is the future, I would not be here.
Heh... Same with me. Go might have a future, not much of one with me however.
... With the result that cstring now means compatible string.
Yeah, I reached a similar conclusion (on all the c prefixed types, as I have used nim js quite a bit).
In regard to cint, where int in not in javascript, one can think of it as compatible with the underlying implementation.
It would be nice to eventually see all the items needed to interface with new backends broken out into their own modules, to make creating new backends much easier. Note I said eventually...
Everything is split more explicitly, and there is no system wide hybrid type that has to be compatible with whatever the backend is.
So, one cstring for char*, one for std::string, one for NSString and one for JS' string? That looks like an awful lot of string types.