> ctrl-f cast: 0 hits Huh. I'm not clear on why passing a `string` to a `cstring` parameter works in your code but not when I try it. Or is passing a string literal somehow different than passing a variable?
> It's still not good enough to be part of a Nim library's public API Agreed. And I'm more concerned with APIs. I've seen Nim APIs that just blithely expose C functions (I believe one for libSodium or Monocypher does that, which is ironic considering that security-related code is the last place you want to have buffer overruns or use-after-free.) I realize you deliberately chose a simple example for clarity. In more complex code, where the C stuff has more complex types and is called more often, IMO the C calls should be wrapped once in a safer internal API. That's what I tend to do. > You're looking at a language construct that does nothing but suppress a > compiler error and you're seeing a contract somehow. `unsafe` is the means of _expressing_ a contract, not _enforcing_ one. It's not possible to enforce safety (without disallowing things like pointer dereferences or C calls entirely); if it were, we'd run such an enforcer on all our code and never have to worry about crashes again. It's kind of like the way a `raises` pragma is used to _express_ a contract that the function internally handles any (checked) exceptions other than the ones listed. Internally the function could just be catching and ignoring other exceptions because a lazy programmer just wanted the compile error to go away — I've seen Java code like that in the past. That would be a violation of the contract. Again, you can't automatically _enforce_ the contract that the function handles the exception properly, because that's a human-level cognitive task. > So you need a nudge for users to meet those extra requirements (something > like unsafe fns, that require unsafe blocks from callers). Yes, which unless I'm misunderstanding you, is the same feature I'm proposing. (?) In your example you're proposing `unsafe` to express thread-safety, which I don't think is appropriate because thread-safety is a higher level global property of the program. Avoiding feature creep, I think it's beast to reserve `unsafe` specifically for the things it means in Rust. Also, adding more 'obligations' of some sort to an existing public API function would be bad design. That's the sort of thing that led me to give up PHP in disgust in 2005 — "In version 5.0.3 or higher, if x is negative then foo is interpreted as a pointer to int32 and must be 4-byte aligned or you may crash." 😫
