more than one kind of "unsafe"

[torpak]

Currently as far as i understand it the unsafe keyword only applys to potentialy breaking memory safety guarantees.

Some people argued that other types of guarantees like leak-safety, safety from panics, ... would be useful and violating those should be considered unsafe too.

The most important argument against this seems to be that this would weaken memory safety because it would lead to an inflationary use of unsafe.

My ideal solution to this would be not having just one unsafe keyword but at least three, maybe many:

• unsafe_memory_access
• unsafe_potential_leaks
• unsafe_could_panic
• ...

Code that can not accept one or more of those types of unsafety could opt out of each specifically.

Since 1.0 is out this scenario is not realistic any more.
But maybe we could have something like:

• "nopanic" which would raise an error when the compiler can not prove, that the code in question does not panic.
• "noleak" which would raise an error when the compiler can not prove freedom of leaks
• ...

Since a practical compiler has to run in finite time it can on it's own only ever prove the most trivial cases. A mechanism would be needed to assist the compiler.

The most simple form would be corresponding attributes wontpanic and wontleak.
For example i want to call a function that could theoretically panic inside a nopanic block, then i would make sure that i call this function only in ways that are guaranteed not to panic and wrap the call inside a wontpanic block.

Use of reference counting inside a noleak block could be done the same way.
This could be added in a backward compatible way and nopanic and noleak... should be added where ever possible.

[torpak]

This would solve many of the problems voiced in #1066 .

[arielb1]

@torpak

Panics are not a kind of undefined behaviour. It is safe for code to intentionally panic.

[codyps]

@arielb1 true, but it might also be useful to be able to mark things (blocks or functions) as non-panicable, I believe this has at least been discussed in the past. @torpak it might make sense to place the question of marking panic-producing (or non-panic producing) code in a seperate issue as it seems to be a slightly different concern.

[seanmonstar]

A prototype could likely show these off using lints and attributes.

On Sun, Jun 14, 2015, 11:13 AM Cody Schafer notifications@github.com
wrote:

@arielb1 https://github.com/arielb1 true, but it might also be useful
to be able to mark things (blocks or functions) as non-panicable, I believe
this has at least been discussed in the past. @torpak
https://github.com/torpak it might make sense to place the question of
marking panic-producing (or non-panic producing) code in a seperate issue
as it seems to be a slightly different concern.

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

[torpak]

On Sunday, June 14, 2015 11:06:00 arielb1 wrote:

@torpak

Panics are not a kind of undefined behaviour. It is safe for code to
intentinoally panic.

---

Reply to this email directly or view it on GitHub:
#1160 (comment)

That's part of what i mean. I think more in the direction of the literal
meaning of unsafe than the meaning that the keyword currently has.

And while i think it is to late to change the meaning of the keyword in any
significant way, i think it could be useful to mark (and check) code as not
containing some specific kinds of footguns that are not covered by the current
unsafe semantics.

When i have to mark code as unsafe, for example to do some optimization, that
i know is safe but can't prove to the compiler to be so, i know i have to take
extra care to be sure i'm right.

With my proposal:
when Code is not marked as noleak, for example because i want to use
refcounting, i know i have to take extra care not to leak memory.

I wish noleak nopanic and whatever footgun avoidance else the compiler could
help with, were implemented and active by default and explicitly disabled on
individual basis when needed like with the unsafe keyword but it's to late for
that.

thus my proposal.

[torpak]

On Sunday, June 14, 2015 11:13:36 Cody Schafer wrote:

@arielb1 true, but it might also be useful to be able to mark things (blocks
or functions) as non-panicable, I believe this has at least been discussed
in the past. @torpak it might make sense to place the question of marking
panic-producing (or non-panic producing) code in a seperate issue as it
seems to be a slightly different concern.

I intentionally named nopanic as one example.
Think of it as a statement of expectation for a block.

Whenever my code does something i don't expect it's bad.

But manually checking all my code for anything that could go wrong is tedious
and error prone. Every bit the compiler can help is good. This is my reason
for looking at rust in the first place.

Now if i state an expectation for a block like no
i don't expect this block to ever do , where can be panic, memleak,...,
please compiler tell me can i be sure of that, and if not, where do i have to
have a closer look?

I know that each of these expectations is hard to implement and each will need
a way to tell the compiler "i have manually checked this block and i'm
reasonably sure it doesn't do X" because otherwise compilation will not
terminate for all cases.

But i'm relatively sure for many of these hazards it's possible to prove their
absence automatically and in reasonable time for a great majority of common
code.

[steveklabnik]

You might be interested in https://github.com/rust-lang/rfcs/pull/73/files

this kind of thing is usually called an 'effects system'

[torpak]

ah that is very close to what i meant.