Anything not defined in Rust needs to be marked as unsafe, because Rust cannot understand non-Rust code. FFI bindings are inherently unsafe.

On a side-note; do you know of any good resources where someone tries to wrap a non-trivial C wrapper where they go over common C idioms and ways to provide a (safer) API inside Rust without too much overhead?

I've always found it to be incredibly difficult because of the number of gotchas which can leak into causing a segfault in Rust; it's immensely frustrating.

My co-author Carol Nichols gave a few talks on this a while back, but there's not a ton of resources, it's true. I would look at big libraries and see what they do. I know it's not the best thing, but it's probably the best that exists right now.

I think maybe the ZeroMQ rust crate as a case study is something that is non-trivial: https://github.com/erickt/rust-zmq

It's more of an example than a resource, but the 'git2' crate that wraps libgit2 does a good job of providing a nice rust interface over a C library.

It's a call out to Windows libraries that long predate Rust, and they are implemented in (mostly) C++. They don't provide any of the safety features on any data structure you pass to it. I don't see how it could be anything other than unsafe.

Yet the xcb bindings in that crate are mostly safe: https://rtbo.github.io/rust-xcb/xcb/xproto/fn.create_window....

They have provided nontrivial wrappers, wrapping xcb datatypes so to make them safe and uphold the invariants.

I don't know much of any Windows interfaces, but I doubt this would be impossible there too; they simply did not do so.

Does it actually wrap libxcb, or does it generate bindings from the XCB protocol descriptions (XML)? I would think the latter would be less work and higher quality.

I don't know how it's achieved, but as I look at the bindings for this Windows a.p.i they return all sorts of raw pointers and other things, whereas in XCB bindings for Rust wrap the types in a Rust-friendly way so almost all of them are safe.

This Windows a.p.i. in Rust seems of a frankly atrocious design and most of the functions seem simple `extern "C"` declarations rather than actual attempts at proper wrapping.

I don't think that's a fair characterization. Most safe rust wrapper libraries are built in two layers: 1. Map the api's raw interface into raw rust types, usually with a simplistic code generator; this enables the bindings to closely track upstream api changes. 2. Use that raw interface to build a wrapper library that translates the api to use rustlike idioms and expose safe constructs.

This seems to be #1 only for now, which is fair because winapi is enormous. Also there may be many ways to expose a safe rust interface all with different tradeoffs, by leaving #2 open they don't lock in a single strategy prematurely. That said I am looking forward to a safe wrapper as well.

That it is atrocious because the project is young, and that it might become less atrocious in the future, is no argument that it not be atrocious.

However, my original reply was to this:

> It's a call out to Windows libraries that long predate Rust, and they are implemented in (mostly) C++. They don't provide any of the safety features on any data structure you pass to it. I don't see how it could be anything other than unsafe.

It very much can be, and is often done, it simply isn't (yet )here.

Hating this is like hating a primer-painted part for being grey: you denounce the propose and existence of primer and claim that it should have been painted with the finishing coat from the start.

I'm sorry you think the dull finish is ugly, but looking pretty is not its purpose. Its purpose is to bind strongly to the substrate it's on and provide a better surface for that shiny coat you so desire to adhere onto. Primer and language bindings alike.

> Hating this is like hating a primer-painted part for being grey: you denounce the propose and existence of primer and claim that it should have been painted with the finishing coat from the start.

No, it's simply arguing against the claim initially made that there is no way for it to not be grey.

> I'm sorry you think the dull finish is ugly, but looking pretty is not its purpose. Its purpose is to bind strongly to the substrate it's on and provide a better surface for that shiny coat you so desire to adhere onto. Primer and language bindings alike.

Maybe it isn't it's purpose, but the original post claimed that it was impossible for it to be difference, which is certainly false.

The Windows API is a sprawling mess.

I really doubt that would have anything to do with whether or not the binding wrote safe, Rust-esque wrappers or not.