Methods that can fail (panic) should be marked as unsafe

[sergei-kucher]

Some of core methods using fail! macros. Like expect and unwrap of core::option::Option and core::result::Result.

I found two primary things about this:

• RFC: rename fail! to panic! (issue)
• Common container/wrapper methods [RFC] (issue, issue)

Seems like some of fail (panic) methods will be preserved (like expect for a Option<V>). But using of such methods is highly error-prone.

To prevent mass usage of them I suggest to mark such methods as unsafe.

For example:

unsafe fn expect(self, msg: &str) -> T

[sinistersnare]

unsafe is used for operations that are memory unsafe. marking (supposed) code smells as unsafe would only pollute when or when not to use it. notice memory unsafe is a very clear definition, unsafe does not mean this code might be broken, per se. (as i understand this)

[thestinger]

unsafe is for drawing a boundary between memory unsafe and memory safe code

http://doc.rust-lang.org/reference.html#unsafety

It's not used to discourage the usage of safe APIs as that would break down the boundary and make it harder to identify memory safety issues. Usage of unwrap and expect is common in correct code, because there are invariants that are not encoded into the type system. Changing the meaning of unsafe would be a fundamental change to the design of the language / libraries so it would need to go through the RFC process (but it wouldn't be accepted).

[thestinger]

(now at rust-lang/rfcs#340)