Extending the unsafe keyword

[scottmcm]

@DragonDev1906

but are there any plans/discussions about extending unsafe in a way (or using a different keyword) to indicate that regardless of how you call this function it will not end up in undefined behavior or memory safety issues, but special care must be taken to use it correctly.

I don't know how to draw any line for this, really. Does reading a file need special care because it might be outside the directory you expected and leak information? Does HTTP need special care because you might be uploading your password to pastebin instead of your password manager? Does implementing Ord need special care because you might be binary searching for something you need to actually find?

The simple thing here is to make the function name longer for something that needs to be used carefully. Rather than unsafe<SomeIdentifier> fn foo you can fn foo_some_identifier. So it's not obvious to me that specific extra syntax is worth it overall.

Today's unsafe is distinguished because if violated you can't trust what you see -- telemetry might be wrong, checks that you see might not happen, etc. That's very different from correctness issues, where the code might be wrong but at least you can debug it, check logs, etc.