Language vision regarding safety guarantees

ia0: > Is it because "ensures" are meaningless in general? (which I hope I addressed in the previous quote) Otherwise the distinction is what the crate author wants to guarantee for which purpose. To take the sort example again, the crate may choose to guarantee a stable sort for logic and a permutation for safety. Or anything else. I'm sure there must be some gaps between us What is the difference for the library author when writing the code that guarantees a stable sort for logic or for safety? Maybe figuring out this could help me understand your opinion. In my understanding, the difference of logic and safety makes sense for me when it stays for contract requirement: If user wants this contract to fit requirement of downstream unsafe function, then it is safety contract; otherwise it is logic contract. Anyway, the safety or logic is decided by consumer instead of producer. If there is no difference in code-level to provide logic / safety "ensures" contract for author, then I would say that there could be a unified "ensures" contract, and let the consumer to choose whether it is for safety or logic.