rename 'unsafe' to 'trusted.'

[steveklabnik]

unsafe blocks are one of Rust's most important features. However, the name "unsafe" doesn't properly communicate the intention of unsafe blocks. I propose we change the "unsafe" keyword to "trusted," initially deprecating it.

[lilyball]

This seems to imply that normal users of Rust should be using unsafe blocks as a matter of course, and I disagree. unsafe should largely be used when building reusable fast components (e.g. the standard library), but most users should be using exclusively safe APIs, only needing to fall down to unsafe when they have a performance bottleneck and simply can't avoid it.

To that end, I greatly prefer the current name unsafe. Merely typing it out makes me pause, because I'm entering code that the compiler cannot verify is safe. Which means that the code inside an unsafe block may in fact be unsafe in reality, and it's up to me to prove that it is actually safe.

[huonw]

I'm slightly concerned this name may get confused with "I've checked this code and trust it" (i.e. arbitrary "bug free" code), rather than "the compiler is trusting me" (i.e. dangerous code).

[steveklabnik]

This seems to imply that normal users of Rust should be using unsafe blocks as a matter of course, and I disagree.

I also disagree, however, they need to know that unsafe exists. Before I mention unsafe, many people assume Rust cannot replace C or C++, because they don't think certain kinds of low-level primitives can be implemented. This is also why the 30 minute introduction mentions unsafe.

[ben0x539]

Are you suggesting this for unsafe blocks only or also unsafe functions?

[bstrie]

@steveklabnik, the keyword unsafe better conveys Rust's abilities to replace C/C++ than trusted.

Either way, you'll have to explain to someone that Rust can do these low-level shenanigans. unsafe is both a visual warning and a subtle discouragement. Your unsafe code is unsafe, and to imply otherwise is wildly dangerous. -1 from me.

[bstrie]

That said, I'm not about to assert that unsafe is necessarily the best possible keyword for this, though it's a good one. Whatever keyword you choose has to imply unsafety rather than safety. If you don't get subtle anxiety from the presence an unsafe block, we've failed.

[ben0x539]

We could make unsafe { ... } blocks into extern "C" { ... } blocks to make it absolutely clear that C-style code can be written in rust ;)

[mcpherrinm]

I like the term "barrier" to describe what an unsafe block provides. On its own, I don't think it conveys the right terminology, but I'd like to at least fling it into the vocabulary mix here.

I have definitely been convinced that unsafe { } is not the right syntax. It doesn't convey at all that it's a barrier, and should be safe itself.

I don't exactly like "trusted", as it goes too far the opposite way. "unchecked", maybe is a good word.

[bstrie]

I have definitely been convinced that unsafe { } is not the right syntax. It doesn't convey at all that it's a barrier, and should be safe itself.

"Should be safe" presumes optimism. Rust is not an optimistic language, it is a pessimistic one (as are all languages with strong static type systems). Your unsafe code is unsafe, and you should feel unsafe. (Sorry, I'm too lazy to track down the Zoidberg meme generator.)

[mletterle]

I would propose a small change.. rather than trusted try trustme.

[crazymykl]

trusted is less-than-ideal because it implies that other code (with stronger guarantees) is "untrusted".

unsafe is more similar to hold_my_beer_and_watch_this; but trustme might be more terse/appropriate.

[mcpherrinm]

"Should be safe" presumes optimism.

I don't think I agree with your sentiment: If an unsafe { } block can be used to cause unsafety, then that code has bugs. We should convey the intended purpose of unsafe blocks: to denote the edge of unsafety, where the guarantees have been made.

[UtherII]

IMHO, even if "unsafe" can be misleading, "trusted" is far worse. When people will see "trusted" block, they will have the feeling, that the block is safer. It's quite the opposite. "unchecked" would be closer to reality but not scary enough to convince people that it should be avoided as much as possible.

I still think that unsafe is a good choice. We can advertise better this feature without renaming it.

[brocktopus]

What about something like "unwise" or "inadvisable"? If the intent is really to keep people away from its common use--but not so much as to outright prevent that use--"unsafe" may be too much of a judgment call on the quality of code written with that kind of block (i.e., an entirely unsafe practice) compared to a name that implies a standard preference?

[ben0x539]

unverifiable, uncheckable?

[andrew-d]

👍 for unverifiable or unverified

[shepmaster]

Adding to the madness:

(un,non)
guaranteed,verified,verifiable,checked

[thestinger]

@brocktopus: It's not unwise or inadvisable to use unsafe code. It should be limited to when it's absolutely necessary for performance or to implement the building blocks for unsafe code but that still leaves plenty of reasonable unsafe usage. Writing Rust code that's comparable to the performance of C or C++ usually means making careful usage of unsafe. The common cases can be included in the standard library, but it will never cover everything. It can't just be brushed away as something that's not necessary.

[carols10cents]

I barely have any context for the connotations of what the unsafe feature needs to convey, but in general I would prefer a positive phrase rather than a word starting with un/non (while still having a negative meaning). This is because code like unless !undeselected (exaggerated but I know you've seen code like this) is harder to reason about with double (triple, etc) negatives.

dangerous? scary? risky?

[polyfractal]

If the name changes, I think it is important that the new name accurately describes what's going on, rather than relying on human fear. It's just telling the compiler "hey, I got this, you can go take a nap". If it also conveys that the operation is potentially risky, that's a happy benefit.

Of the suggestions, I like unchecked, unverified, and trustme the most so far. They clearly state that the compiler is trusting you to Do The Right Thing.

[Thiez]

-1. I like the way that unsafe is subtly discouraging. Its use really should be kept to a minimum, and a keyword that is slightly distasteful to have in your code will help with this. A word like trusted just doesn't quite evoke the appropriate amount of dread .

I also think unsafe has a clear meaning. There are some things that are defined as unsafe in the Rust language, and they can only happen in blocks that are marked unsafe. Easy to remember, and the link between unsafe blocks and unsafety in the language spec is easily made.

Whatever keyword is chosen, I think it should clearly suggest that the code it guards is more likely to do something bad/unsafe/buggy, while something like trusted suggests the opposite.

[mcpherrinm]

Unsafe does have precedence, as C# does the same thing: http://msdn.microsoft.com/en-US/library/t2yzs44b.aspx

[steveklabnik]

A small survey:

Idris uses trustme, I'm inclined to change this RFC to that. ;)

Haskell's got unsafePerformIO, which isn't exactly the same thing...

OCaml has Obj.magic.

[steveklabnik]

Are you suggesting this for unsafe blocks only or also unsafe functions?

This is a good point. Unsafe functions and unsafe blocks have different semantics, actually. Hrm.

[steveklabnik]

Whatever keyword you choose has to imply unsafety rather than safety. If you don't get subtle anxiety from the presence an unsafe block, we've failed

While I agree, I think this anxiety can come from social pressure, rather than being super inherent to the language itself. In other words, I think that the invariants are the most important information to convey, not the details.

[steveklabnik]

@Thiez

I also think unsafe has a clear meaning.

Dozens of conversations I've had with people just learning Rust disagree with you. I agree it's not hard to learn; but if people outside of Rust get confused, that's a good pointer that this is a bad name. Once you learn it, it's not that bad, but why not be clear what you mean from the start?

[steveklabnik]

I actually think trustme is a much better name than trusted, and am considering updating the text to reflect it.

[dobkeratops]

the existing name,unsafe{}, makes perfect sense to me. There are safe operations(which the compiler can verify), vs unsafe operations (which you must test and verify by other means).
What happens if a rust program has a segfault? you should look at the unsafe blocks. that makes sense. +1 to the comment that unsafe conveys that rust is a suitable C/C++ replacement. It reassures you that there is no 'safety net' holding you back from implementing anything you want, its' just you have to clearly mark it.

[steveklabnik]

I would also like to add some context here too: I have given more Rust presentations than anyone else that I know of (6? Anyone beat that?), on three continents. I've specifically been teaching people Rust for over a year, and have taught programming as a profession for a few years. I'm not saying that means that I'm correct, just that I may have run into this more than other people have, since Rust advocacy is a large part of what I do.

I want to be clear that I think unsafe is a bad name more than I think trusted is a good one.

[thestinger]

I think changing unsafe for blocks but leaving it the same for functions will be much worse than the current naming scheme. The meaning of unsafe for functions also doesn't mean that calling them is unsafe, it just means the compiler can't verify that calls to them are safe (just like unsafe blocks - at the moment it's consistent). If blocks use trusted, then functions should really use something like untrusted or it won't have a consistent overall design. I prefer leaving both a unsafe, meaning the compiler can't verify the safety (which is by definition unsafe, and unsafety does not imply incorrect at all).

[steveklabnik]

No, unsafe functions are different: you cannot use an unsafe function
without also wrapping it in an unsafe block.

[thestinger]

Both unsafe functions and blocks permit the same things (dereferencing unsafe pointers, calling unsafe functions) in the contained code. They both define a section of code where the programmer is responsible for safety. The term unsafe means lack of safety, not undefined behavior. It implies that the programmer is now responsible for preventing undefined behavior. An unsafe block is a safety boundary, but it has an internal meaning rather than just the external one. It defines a boundary between safe and unsafe code, and I think unsafe is a far better term for that than trusted, especially since it's consistent with unsafe functions where it has the same meaning in a slightly different context.

[sinistersnare]

I dont think we should use trusted because we should not trust unsafe blocks, we need to scrutinize them.

If I had to change it, I would say that it should be called unchecked which is exactly what it is, not checked, so we need to do the checking manually.

if we use the word trusted or proven it sounds as if we know that it is just as safe as any regular block, which it is not. Unsafe is used because it alerts the programmer to double check everything in the block. Unchecked, I feel, is more correct than unsafe, as it does not imply bias, and it alerts the programmer accordingly.

And on a tangent, the quote is wrong in the "motivations" section:

This code is not able to be determined to be safe by the compiler, but I promise you that it is.

We should never 'promise' that it is, because that could be misleading. The compiler makes us promises, it knows what it is doing; we may not know what we are doing, and we should not be making promises like that.

But for unsafe, it has precedence with Haskell at least, so -1 to trusted, +1 to unsafe, and +2 to unchecked

[alexchandel]

@jcdyer Exactly, it has all the right connotations.

@steveklabnik

No, unsafe functions are different: you cannot use an unsafe function without also wrapping it in an unsafe block.

That's a great reason to call functions untrusted. Why not call the blocks trust then, to parallel this?

Edit: posting error

[errordeveloper]

How about suspicious, dangerous or even doddgy?

Looks like this discussion has more points towards not renaming actually. I don't seem to see any reasonable argument here on why it needs renaming. It's a pretty keyword and does indeed associate with what it means.

May be syntax needs to be made more horrid, like make user have to prefix each new line with a ! or something of that sort?

fn foo() {
!! hello();
!! and_die(void);
}

Or, actually, may be requiring them to type the attribute like this instead?

fn foo() {
#[UNSAFE]      hello();
#[UNSAFE]      and_die(void);
}

[errordeveloper]

By the way, has anyone attempted to propose --screw-the-safety-rules-i-am-a-masochist flag yet? If not, sure someone will, may be as a side effect to some not so obviously named flag... I'll bet.

[errordeveloper]

commit f947b3f0b8e5d08cb4e677419d868ee8d641f55d
Author: Joe Blockes <jblockes@google.ie>
Date:   Fri Jul 13 21:27:29 2017 -0000

    Add `--i-am-feeling-lucky`

[raindev]

I'm new to Rust. unsafe is clear but scary a little bit. trustme is fun, I like that.

blackhole
Clearly denoting that we are reaching somewhere beyond where rustc could look and keep us safe and warm. …where time and space doesn't exists and our program could collapse :P

I see analogy between unsafe and Java'a concept of checked exceptions. It's like unsafe function make context calling it unsafe. Using unsafe block you're getting back that assumption of safety, keeping it in you local context, unlike unsafe function. To summarize the difference is all about if safety could be guaranteed in a current context.

made_safe (unsafe) block shields us from unsafe functions. That's it.

@ecl3ctic and @brandonson made great points on that differences explanations.

[liigo]

when you try to explain what is trustme or blackhole, you say "it means
unsafe code".
yes, unsafe is the essence. i don't think it need rename.

[steveklabnik]

I am closing this RFC. I still think that this is a poor name, but I plan on seriously revising this RFC anyway, and the discussion here will largely be irrelevant.

I will open a new RFC when I have a better plan. Thank you all.

[pczarn]

You're welcome. IMO trusted fn / trust {} is decent, but not a strict improvement.

[iopq]

How about renaming them safe? That means "I, the programmer, claim this code is safe, I swear"

You wouldn't call them unsafe blocks, you'd call them blocks declared as safe by the programmer. In other words, explicitly safe blocks as opposed to implicitly safe blocks (everything else).

[sinistersnare]

I do not understand any of the arguments for using a positive word, the code in an unsafe block should _not_ be trusted, everything else in the codebase should be trusted. If we have to change it (which we do not) I would again vote for unchecked, even though that is not perfect either.

[iopq]

unchecked means "array indeces are not checked to be in bounds, stack is not checked for overflow, etc." which is actually not true in unsafe code, unsafe code is still checked

[sinistersnare]

Perfect, unsafe it is.

[nathanaschbacher]

I don't understand the war against the unsafe terminology. It's
perfectly reasonable. It makes the most sense to me. "In here lies
potential danger."

On Mon, Dec 22, 2014 at 2:32 PM, Davis Silverman notifications@github.com
wrote:

I do not understand any of the arguments for using a positive word, the
code in an unsafe block should not be trusted, everything else in the
codebase should be trusted. If we have to change it (which we do not) I
would again vote for unchecked, even though that is not perfect either.

—
Reply to this email directly or view it on GitHub
#117 (comment).

[glaebhoerl]

The basic issue is that unsafe { ... } means both "this has the potential to be unsafe" and "but you should make sure that it's actually safe". That is the source of all the confusion and bikeshedding. (Which I don't think is very surprising, personally.)

Hence why I think the best way would be to decouple the two: keep unsafe only as a marker of places where unsafe operations may be invoked, and have a separate construct (perhaps at the whole function level, perhaps called trusted) to do the other half, which is to assert that the whole is safe even though its individual parts may not be. (There was an RFC somewhat along these lines, but it was closed.)

[raindev]

Wouldn't trusted be redundant that way? As I understand, all the functions are considered safe (having only safe checked code) until unsafe is involved.

[ghost]

flammable?

[iopq]

inflammable?

[glaebhoerl]

@raindev Normal functions don't need to be trusted - the type system guarantees their safety. Only functions which may violate safety need a level of explicit trust. You're right that a trusted fn would be outwardly semantically indistinguishable from a normal fn: this is more about having the programmer clearly express her intent (an fn containing use of unsafe may be either an unsafe fn or a trusted fn - for an fn without unsafe blocks, there is no choice to make). But perhaps trusted could show up in the generated documentation, and perhaps it could also have ramifications for lints and tooling.

[sinistersnare]

if unsafe -> trusted/some_positive_word, the what would regular code be? untrusted?

[nathanaschbacher]

This entire topic seems like it should be used as the poster child for bike
shedding and/or pedantry.

unsafe makes complete sense. The thing that makes safety in Rust is the
compiler, not the programmer. That block marked as unsafe is a place
where the compiler's guarantees of safety are not in effect, and the level
of safety is left up to the programmer.

The point of the language unsafe as a keyword isn't for passing judgment
on whether an implementer did or didn't manage to make their own safe
implementation, it's to signal contextually to the consumer that rustc
isn't going to save you from something dangerous happening in there, and to
signal to rustc to go ahead and let you do something dangerous.

Forest. Trees.

Cheers!
On Dec 25, 2014 10:22 PM, "Davis Silverman" notifications@github.com
wrote:

if unsafe -> trusted/some_positive_word, the what would regular code be?
untrusted?

—
Reply to this email directly or view it on GitHub
#117 (comment).

[tshepang]

@nathanaschbacher great comment