Unsafe blocks and sub-language

[graydon]

Add a new raw-pointer-to-T type constructor *T, and a lexical block type 'unsafe { ... }' in which a few new operations become allowed: forming a raw pointer with unary &, dereferencing a raw pointer with unary *, casting a raw pointer to another raw pointer with binary 'as', indexing into raw pointers with ".()" (soon to be []), and performing arithmetic on raw pointers.

[brson]

I've been talking to pcwalton about this and he's of the opinion that we should do these unsafe operators through library functions, via intrinsics, some of which we already have and use. I can see the advantage of that, in that it's easier than supporting more language features. It does demand cross-crate inlining though.

In either case we still need a way to mark the boundaries of unsafety.

I believe what he likes, and what I agree seems nice, is that:

1. Native and intrinsics are implicitly unsafe
2. Functions that are declared unsafe may call other unsafe functions
3. Functions that are not declared unsafe may wrap calls to unsafe functions in unsafe blocks, thereby wrapping the unsafety in safety

I think this closely parallels what we're doing with purity/checking; if not it should.

[graydon]

it needs a special case to cover for the "scrubbing" of an unsafe function into a safe one by taking a first-class reference to it. This should be prohibited; you have to make a "safe" function (un-annotated) with an unsafe{...} block that calls the known-unsafe one.

Otherwise there's not much point checking it. This is ... really an "effect" system that doesn't handle 1st class functions. Not a very strong one; mostly just for documentation purposes.

[brson]

If we went the direction of using intrinsics for unsafe pointer operations we would probably want to get rid of pointer assignment and dereferencing operations and make them intrinsics as well, for consistency.

[graydon]

Seems like overkill to me to be including assignment in this list. Surely "x = y" on pointer types is not a costly language feature to support. Or do you mean address-taking (unary & in C)?

Or are you thinking of removing raw pointer types altogether? Can you write down a list of the operations and types you think are important, and mark your preferred implementation technique for each (library call, language operator, type, etc.)?

[brson]

I was thinking that, if we implement pointer operations mostly as library functions, then it would make sense to try not to implement pointer types in the language at all - just make them a type-parameterized tag containing an address.

[nikomatsakis]

At this point, I have implemented unsafe functions and blocks and will be submitting pull requests today. Unsafe operations include invoking unsafe functions and dereferencing pointer types. Native functions are not unsafe by default---that was considered too much overhead for insufficient gain---but can be marked as unsafe if desired, just like other functions.

[brson]

So this seems pretty well done. Do you think we're ready to close it, niko?

[nikomatsakis]

yep. May turn out that there are a few more unsafe operations to add but that will be simple to do.