warning about unneeded unsafe functions is wrong

[thestinger]

It can't know that the function is safe because it doesn't require unsafe code. A function can break invariants in private data that are relied upon by unsafe blocks elsewhere in the module.

The unneeded unsafe block warning is great, but I think the function equivalent should be removed.

@alexcrichton

[alexcrichton]

It's certainly easy enough to implement, does this come up very often? I'm having trouble thinking of concrete examples.

The connotation of unsafe to me means that it should be used as little as possible, and if you have some sort of invariant it would rather be wrapped in assert! instead of unsafe.

[thestinger]

I don't think it comes up often, but poking a hole through the API seems like a valid use case for unsafe functions. For example an object might use a raw pointer internally assumed to be valid and allow setting the field to another value through an unsafe function. Obtaining a raw pointer and assigning it to a field is considered totally safe.

[pcwalton]

The other use case for this is if you're implementing a function on a trait that is marked unsafe because an implementation for some other type needs to be unsafe, but this type implementation doesn't need to be.