Since secure_clear takes trivially copyable arguments,
the compiler is free to make arbitrary additional copies
on the stack, in registers, or elsewhere. Clearing
just one of the instances is not enough to achieve the
stated use-cases of this function. A security feature
that doesn't reliably deliver should not exist in the
Taking a step back and ignoring performance concerns, if secure_clear only worked on trivially copyable volatile objects, would that be sufficient? If so, would some kind of volatile_ref<T> class (similar to atomic_ref<T> vs. atomic<T>) work? Just brainstorming here. Without some way to indicate that we have memory that we want to eventually securely clear, I don't see a way to solve this.