New function colour: unsafe

Evolution Discussion
,
95

I sort of agree this should be the goal. But all C functions can access global variables which will include pointers and thus can be unsafe. Maybe it's a good idea to assume they don't do that in general, but it'd be nice if there was an annotation to differentiate what is assumed safe from what we're sure is safe.

We could have three levels: "safe & audited", "assumed safe", and "known unsafe", where "assumed safe" would be the default. It's a bit similar to implicitly unwrapped optionals but unfortunately without a way to check for safety like we can check for nil.

Most Swift code would then fall in the default "assumed safe" category. You'd use the "safe & audited" flag when you actually want to audit things and have the compiler flag any caller not audited yet.

I suppose it could look like this:

 // safe & audited
safe func foo() {
    safeCall() // ok
    trust { assumedSafeCall() } // ok
    trust(unsafe) { unsafeCall() } // ok
}
// assumed safe
func foo() {
    safeCall() // ok
    assumedSafeCall() // ok
    trust(unsafe) { unsafeCall() } // ok
}
// known unsafe
unsafe func foo() {
    safeCall() // ok
    assumedSafeCall() // ok
    unsafeCall() // ok
}

This sounds a bit like @tera's "unmost safe" concept, but it's different in that the "safe & audited" can still call unsafe and "assumed safe" functions (within a trust block).

The biggest risk with the general concept of unsafe is source breakage when the unsafely level is increased. This can happen either when something was too eagerly marked "safe & audited" or because something previously assumed safe suddenly becomes "known unsafe". If we want to avoid source breakage, we need to limit what becomes "unsafe" and be very sure of ourselves when marking something "safe & audited".

1 Like