Language vision regarding safety guarantees

ais523:

he interesting thing about this method is that it's marked unsafe, even though abusing it shouldn't be able to cause undefined behaviour (only logic bugs):

Whenever an API marked as unsafe causes only logic bugs when misused, rather than actual memory safety issues, I think it's best to ignore the logic thing and suppose that, even though currently it does not actually trigger UB, in the future, new semver-compatible versions of this API hold the right to trigger UB "as promised". So the API is allowed to trigger UB when misused (and allowed to do anything else, including having a safe logic bug), but not required to do so at any given moment.

So what the stdlib is saying is that it could, at some point in the future, actually trigger UB in this operation, even if it's not doing this today. And as such, it's UB in this sense (you do something, it might cause UB sometimes, you can't rely on it to not be UB, ergo it is UB in some abstract sense)

If it actually triggering UB is not a sensible future direction for this API, it seems much better to just remove the unsafe tag from it (existing callers won't be negatively affected, but they may drop the unsafe block if they wish)