3 ms·

Trivial destructibility alone is generally sufficient for that in Rust. Recall that all values (outside a Pin) are trivially moveable, so pretty much the only r

Trivial destructibility alone is generally sufficient for that in Rust. Recall that all values (outside a Pin) are trivially moveable, so pretty much the only reason you'd want trivial copying is if you actually need more than one valid copy at once. (One exception is using Copy to express a poor man's Freeze bound, which is quite limited, and dubious in any case.)

mmastrac 2y ago
A type that is not Copy may have associated memory allocations, however. You cannot simply forget a range of !Copy structs without the risk of memory leaks.
- LegionMammal978 2y ago
  If those !Copy structs deallocate their memory when dropped properly, then they aren't trivially destructible. If they were trivially destructible, then they would leak their memory regardless of whether you dropped or forgot them. That's what it means for a type to be trivially destructible: dropping it is a no-op.
  - mmastrac 2y ago
    I think we're talking about the same thing -- the original post in the thread used "no impl Drop" as "trivially destructable", not "no functional difference between drop and forgetting".
    - LegionMammal978 2y ago
      Well, I interpret "trivially destructible (i.e. they can't have impl Drop)" as meaning "the type itself can't impl Drop, nor can any of its fields or subfields", which is what it means for a type to be "trivially destructible" in Rust. But what do you mean by "trivially destructible" being different from "no functional difference between drop and forgetting"? Unless I'm mistaken, they are the same thing: if none of a type's subfields impl Drop, then dropping it does absolutely nothing; whereas if any subfield does impl Drop, then it can't be a no-op, since the compiler has to form a &mut reference to pass it into Drop::drop() (a distinction very relevant for unsafe code). Could you give me an example of a !Copy type that is "trivially destructible", but can't be forgotten without leaking memory?

mmastrac 2y ago

A type that is not Copy may have associated memory allocations, however. You cannot simply forget a range of !Copy structs without the risk of memory leaks.

LegionMammal978 2y ago
If those !Copy structs deallocate their memory when dropped properly, then they aren't trivially destructible. If they were trivially destructible, then they would leak their memory regardless of whether you dropped or forgot them. That's what it means for a type to be trivially destructible: dropping it is a no-op.
- mmastrac 2y ago
  I think we're talking about the same thing -- the original post in the thread used "no impl Drop" as "trivially destructable", not "no functional difference between drop and forgetting".
  - LegionMammal978 2y ago
    Well, I interpret "trivially destructible (i.e. they can't have impl Drop)" as meaning "the type itself can't impl Drop, nor can any of its fields or subfields", which is what it means for a type to be "trivially destructible" in Rust. But what do you mean by "trivially destructible" being different from "no functional difference between drop and forgetting"? Unless I'm mistaken, they are the same thing: if none of a type's subfields impl Drop, then dropping it does absolutely nothing; whereas if any subfield does impl Drop, then it can't be a no-op, since the compiler has to form a &mut reference to pass it into Drop::drop() (a distinction very relevant for unsafe code). Could you give me an example of a !Copy type that is "trivially destructible", but can't be forgotten without leaking memory?