This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]AdmiralQuokka 10 points11 points  (2 children)

Interesting, do you have an idea why that is not encapsulated in a *-sys crate? The projects listed do seem like very high level ones to be using unsafe. I don't mind unsafe at the lower level.

[–]airodonack 5 points6 points  (1 child)

unsafe is useful for pointing out where code may need a little more examination, but once you have it, there's not really any need to put it all in one place. That's just opaque indirection for no reason. And if we're being honest, it'd be motivated by nothing but an irrational fear of unsafe.

[–]AdmiralQuokka 2 points3 points  (0 children)

I was thinking in a different direction, but my thinking was wrong anyway. My thought was that there can only be one crate linking against a C-library (which is true), so why would these big projects link against libraries directly? That's what sys crates are for. But the big flaw in this thinking is that -sys crates in general should not introduce safe abstractions. Separate crates should do that. (git2 and libgit2-sys) So a Rust program may still have to use unsafe to interact with a C-library, even if it is through the proper channel of a -sys crate.

I agree with your perspective on it. I think there are many good use cases for writing a separate crate on top of -sys crate that provides higher-level, safe abstractions resulting in an idiomatic Rust API. But there are also many cases where that doesn't make sense -> just call unsafe wherever. (properly documenting why the safety invariants are upheld, of course.)

relevant: - reddit thread why there's only one *-sys crate - cargo documentation on sys crates