Extending the unsafe keyword

[scottmcm]

Splitting the introduction keyword from the elimination keyword has come up many times. I think it'd be a good change -- I tend to call it hold_my_beer for bikeshed avoidance -- but it's hard to weigh the churn of it.

@Raphael

In this case, unsafe is not a block, but a modifier, allowing the following expression or statement to be unsafe

I've never been fond of this. To me, the critical thing is that unsafe doesn't just affect a value (like ? does, say) but that it affects everything in the lexical block. The most recent public release just leaned into that, in fact, with the stabilization of THIR unsafeck. And when something affects a block, I think braces on it are appropriate.

See the following post from the last time this came up for more about what I think is a better way to address this motivation:

Ability to call unsafe functions without curly brackets

I still think that focusing too much on which functions are safe or unsafe is the wrong direction for making this better. It's whether the preconditions are met that's really important, and turning Foo::new_unchecked(x) into unsafe.Foo::new_unchecked(x) or whatever isn't really helping to focus the effort on the important part. The particularly-bad problems I see in unsafe code are not that people don't know which things are unsafe, but they end up focusing on proving one of the preconditions…