> The caller here is what is violating the contract.
"The caller" of the unsafe function is the unsafe block in make_slice. And yes it's violating the contract.
> How would you fix this by only editing the code inside the unsafe block? Because you said the problem is the lifetime. That's outside of the unsafe block.
If it's locked into returning a static lifetime, then the only fix is to return a slice into a static allocation.
Is this the functionality you wanted? Probably not. But an unsafe block having an awkward API isn't an excuse to violate safety. Sometimes the only answer is to say no. Calling from_raw_parts this way is a clear bug.
> How could it? It's just making a slice, it doesn't know what from.
It could know more if you added more to the unsafe block outside the call to from_raw_parts.
> It can't guarantee a slice it makes is ANY kind of lifetime. If it could, it wouldn't require unsafe.
> as long as you change your function so much you can basically remove unsafe, you can fix it from the function.
from_raw_parts exists for situations where the coder can guarantee that the lifetime is valid (no matter what safe code does), but the compiler can't guarantee it (because it's not smart enough).
It's not there for situations where you make the safe code promise to behave.
It does have a lot of uses, in places that do need unsafe. You just happened to make an example that doesn't need it.
The mere ability to "use it incorrectly" and break memory safety is evidence of a bug. Safe rust in a program without unsafe can't use anything incorrectly in that way. Safe rust in a program with appropriately careful unsafe can't use anything incorrectly in that way.
> The lifetime is outside of the unsafe block.
The unsafe block uses the types from the surrounding function, so you can't change those types without double checking the unsafe block is still valid.
> I can change it from static and we still have the same bug.
Change it to something correct and have the same bug?
Because your continued examples look like no. If you make the lifetime arbitrary then it's still messed up, and if you get the lifetime off the vec then the bug is fixed.
"The caller" of the unsafe function is the unsafe block in make_slice. And yes it's violating the contract.
> How would you fix this by only editing the code inside the unsafe block? Because you said the problem is the lifetime. That's outside of the unsafe block.
If it's locked into returning a static lifetime, then the only fix is to return a slice into a static allocation.
Is this the functionality you wanted? Probably not. But an unsafe block having an awkward API isn't an excuse to violate safety. Sometimes the only answer is to say no. Calling from_raw_parts this way is a clear bug.
> How could it? It's just making a slice, it doesn't know what from.
It could know more if you added more to the unsafe block outside the call to from_raw_parts.
> It can't guarantee a slice it makes is ANY kind of lifetime. If it could, it wouldn't require unsafe.
> as long as you change your function so much you can basically remove unsafe, you can fix it from the function.
from_raw_parts exists for situations where the coder can guarantee that the lifetime is valid (no matter what safe code does), but the compiler can't guarantee it (because it's not smart enough).
It's not there for situations where you make the safe code promise to behave.
It does have a lot of uses, in places that do need unsafe. You just happened to make an example that doesn't need it.