Ambiguity of "unsafe" causes confusion in understanding

It seems like a lot of people new to Rust get confused by the dual-use meanings of the “unsafe” keyword:

  1. Declaring a Trait or Function has an unsafe contract that must be upheld to implement/call
  2. Declaring that contracts have been upheld

For example, see this person’s confusion in this post: https://users.rust-lang.org/t/can-we-get-rid-of-the-unsafe-wrapper-of-os-functions/16134

It would perhaps be better if a different keyword(s) were used. For example, use “unsafe contract” (or just “unsafe”) for function/trait definitions and “verified contract” (or just “verified”) for “unsafe” blocks and trait impl’s.

This has been bike-shedded to death I’m sure, but, since it seems to be a significant source of confusion about “unsafety of Rust”, perhaps it is worth another go-round of a discussion in the community and perhaps an RFC? Especially given the new/upcoming 2018 Edition where keyword deprecation could be reasonably accommodated.

Any appetite for that?

NOTE: I first posted this to the General Rust Forum, but, it seems more appropriate tot the “Internals” Forum: https://users.rust-lang.org/t/ambiguity-of-unsafe-causes-confusions-in-understanding/16135

2 Likes

We talked about this pre-1.0, and didn’t come to any conclusive conclusion, IIRC.

So, to your mind, is this something worth revisiting (especially given the upcoming 2018 Edition)?

Also relevant: What does `unsafe` mean?

Perhaps trusted could be used to indicate that we promise invariants are upheld.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.