> Back to the CURL prefix, what is wrong with it?

It prevents stuttering when using it `curl.CURL_*`.

> What would the "CURL" distinct type be without the CURL prefix?

`CURL` isn't a prefix there.

Take more time to think things through.

▲ johnisgood 6 days ago | parent [-]

I did, thank you. Please explain why would anyone (end user of library) ever want "curl.CURL_GLOBAL_ALL", for example? If anything, it should be private. If you really want to go there, sure. I think it is YOU who should think things through. I get that you are filled with hatred, but come on man. Think. Why would anyone want to call "curl.CURL_GLOBAL_ALL" from a binding which is supposed to be used as a high-level curl library? If it is possible (I have no idea) to make it private, then it should be made private. It is not intended to be used by the users of the library, is it? The higher level functions are the ones supposed to be used by them, and they seem to be named correctly from a quick glance.

If you reply, do so without ad hominems and with some respect. Thank you.

▲ thegeekpirate 6 days ago | parent [-]

Last question I'll answer, because you aren't doing any of this is good faith.

You mean `curl.GLOBAL_ALL`, and it's for https://curl.se/libcurl/c/curl_global_init.html

	▲	johnisgood 6 days ago \| parent [-]
		`// CURL_GLOBAL_ALL combines all initialization flags. CURL_GLOBAL_ALL: i64 = 3` It has nothing to do with "curl_global_init()". This - which is a high-level function intended to be called by the users of the library - has: `init :: proc() -> (ok: bool) { return curl_global_init(CURL_GLOBAL_ALL) == 0 }` As you can see, higher-level function calls low-level function. The higher-level function does not have "curl" as the prefix. My question still stands and has not been answered.