On Tuesday, 25 July 2017 at 19:22:11 UTC, Marco Leise wrote:
I understand that you apply D keywords to C types in a best fit fashion, to get some errors from the compiler when you use them in the wrong context. It should work alright in some APIs (maybe you can show me an example).
I currently only use value types, and they unfortunately implicitly convert to all qualifiers.
But since C does not have these qualifiers, one function may be used for shared and unshared resources or the library may even be compiled with or without thread-safety enabled and you have to query that at *runtime*, where you have no help from the type-system. So I believe, relying on the pattern will be frustrating at times as not general enough.
This means you use custom multithreading approach to work with the resources, shared qualifier would reflect it.
What I seek to achieve by slapping immutable on things like file descriptors and opaque types is the use as hash table keys.
Reference types could benefit from this too, I use it regularly in C#, so it's not exclusive to value types. You just fight hash table design here. If this use case is useful, you shouldn't fight with the library.
As the hashed part of hash table keys must not change, this approach enables us to use these types as keys and statically verify immutability, too. Because opaque structs and integer handles are used in C APIs to *hide* the implementation details, the compiler is deliberately left blind.
Blind compiler can't verify anything: it's blind. And ftell and lseek clearly indicate that file stream is not immutable.
Since I/O is thread-safe[1], it should ideally be `shared` the way you put it.
Indeed, but only C11 specifies this.
