Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Right, but if you write a library using only Rust "safe" code, the guarantee is back on the Rust team.

To me, it would be better if libraries using unsafe code were marked.



Here's[0] an interesting idea for forcing crates using unsafe code to be handled specially, while allowing some "blessed" crates through without the special handling.

[0]: https://github.com/rust-lang/cargo/issues/934#issuecomment-6...


That seems like absolutely great idea. I want it already. I wonder why it wasn't processed further, while being 6 month old already.

It is different notion of "blessed" than the original proposal and, IMHO, a much better one. Steve's proposal is quite dubious, I guess. The problem is low standard for the word "blessed" here: in his proposal this badge has no technical meaning, but big social impact. Crate doesn't have to be superior in a technical sense to get this badge, it just has to be "famous", and stuff gets "famous" for various reasons. That's really bad and will get worse when Rust/Cargo will become more popular.

But that "safe/unsafe" isn't a matter of opinion anymore. If a library is known to be unsafe through the "safe" interface: it's a bug, and a crate shouldn't have this badge from a moment the bug has been discovered and until the bug is fixed again (or even longer, if there have been 5 such bugs over the last 2 weeks, even though now they seem to be fixed). It somewhat serves the original purpose (I assume), because it still means that a crate that isn't used heavily enough ("was downloaded N times over the last month") cannot be "blessed" — we don't have all necessary information to mark it as "blessed" yet, so it will help to set "junk crates" aside.

It's worth nothing if a library is made by Github, but is known to be buggy and to leak memory. But it is worth something if a "github API" crate made by John Doe is used by hundreds of people and didn't have a single memory leak for quite a while.


> Steve's proposal is quite dubious, I guess.

I pretty much opened this issue so we could talk about it, not because I think it's a good idea.


Oh, I didn't mean any offense. I'm just commenting on the idea: the original wording of the proposal seems dangerous, but both reem's and yazaddaruvala's ideas definitely have potential.

So you did a good job by starting that discussion. I hope it will have results.


It's all good, none taken! :)


I wonder if this shouldn't be on the "rust" side, rather than on the "crates.io"-side. Considering[1], I think I'd prefer either/or:

    extern unsafe crate phrases; // It's all UNSAFE!
Or: extern crate phrases; // It's mostly safe

    use unsafe phrases::english; // But not English
The idea being, that either phrases wouldn't be imported/give an error -- or everything in phrases except "english" would be imported -- and english would only be imported if qualified with "unsafe".

Either way... I can see this going the way of try/catch/throws in java -- where the usefulness diminishes as lazy programmers (we're all lazy) end up polluting everything with unsafe (just like "throws Exception e..").

[1] https://doc.rust-lang.org/book/crates-and-modules.html




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: