Re: The cstring type and interfacing with the backend.

2016-09-01 Thread Krux02
@flyx you forgot to mention: `std::basic_string`, `std::wstring`, `std::experimental::basic_string_view`, `std::experimental::string_view` and `std::experimental::wstring_view`

Re: The cstring type and interfacing with the backend.

2016-09-01 Thread _tulayang
I really really don't want to hear about anything about GO. GO is a failure language, OK?

Re: The cstring type and interfacing with the backend.

2016-09-01 Thread flyx
> 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.

Re: The cstring type and interfacing with the backend.

2016-09-01 Thread bogen
> 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*

Re: The cstring type and interfacing with the backend.

2016-08-13 Thread Arrrrrrrrr
Yeah, i think c* should belong to its own module. I have some code that relays on it, but this is a needed change.

Re: The cstring type and interfacing with the backend.

2016-08-13 Thread Krux02
You don't need to like Go, to agree that something in Go has ben done in a clean way. If I would think Go is the future, I would not be here. But I can't deny that there are a few things in Go that I learned to like.

Re: The cstring type and interfacing with the backend.

2016-08-13 Thread Araq
My opinion? Everything is fine, document it, Go is fascism.