An Issue I Wish To Raise Awareness On

[Kagamin via Digitalmars-d]

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.