RFC: Disallow 'unsafe' keyword when opening a function body

[brson]

fn is_this() unsafe { }

It's an abomination!

[brson]

unchecked and anything else that can sneak in there as well.

[catamorphism]

Why? I can easily imagine writing a function whose entire body is unsafe...

[brson]

It is useful and even a bit satisfying but unsafe fn foo() and fn foo() unsafe look very similar and act very different. It has caused confusion.

[pcwalton]

Marking as RFC.

I agree with this, and I'd even prefer bringing back, say, the auth keyword in front of unsafe blocks, since unsafe blocks and unsafe effects are very different.

[eholk]

Huh, I don't think I know the difference between these two...

[graydon]

I agree that it's currently the source of confusion and should go. Not sure what to do about unsafe blocks vs. auth keyword. I think it might make sense to look at Niko's proposal for fixing effect propagation through closures and changing the default fn item effect back to pure, with an impure keyword that works both as item qualifier and block qualifier. With or without auth as a prefix (or some other prefix). But I think that's a longer chain of bugs.

[brson]

I converted core to not use this pattern, then started on std. The uv code has many large functions that are entirely unsafe and, under the new scheme, have 8-space indentation. Encountering that made me less enthusiastic about this change.

[pcwalton]

Closing this for now. Feel free to open a new bug about changing the keyword.