I generally like the idea, but I have some questions that weren't addressed:
How will it be implemented for types? I assume it would be derivable. Will it only be derivable, like Copy, or could you create an impl where claim does something different than clone?
How will backwards compatibility work? If this trait has to be explicitly implemented, then many existing user defined types that impl Copy and should be Claim will require a change to those types, and step 3 will break existing code for such existing types that are Copy but not Claim not getting captured by closures and async blocks. On the other hand if all Copy types are Claim, then there needs to be some way to opt out for large types (like the mentioned [u8; 1024]), and existing Copy types that shouldn't be Claim will be.
Then there are array types. The post says [u8; 1024] shouldn't be Claim. But what about smaller arrays? Should all array types be Copy but not Claim? If not, where is the cutoff, and does it depend on the element type?
One of the requirements is that the claim operation never panics. But that actually means Rc and Arc don't meet the requirements because they can panic if the reference count overflows. At least in theory. I'm not sure if that is practically possible on most hardware. It's certainly significantly less likely than failing to allocate.
Finally, how would the requirements be enforced? Would implementing this trait be unsafe for any non-Copy type? Or are these more like guidelines? Would (could?) the compiler enforce these requirements in the implementation of clone somehow?
"Should all array types be Copy but not Claim? If not, where is the cutoff, and does it depend on the element type?"
I think it was mentioned that something should be considered Claim'able if it can fit in a cache line. So I would guess that a heuristic could be used to determine which array sizes are valid to automatically implement Claim for.
I really like this proposal. It's fairly concrete, makes day-to-day coding much more ergonomic and, more importantly, doesn't introduce a great many esoteric concepts that are just going to clutter the language.
I'm assuming not everyone will agree with this, since it's more 'magic' but I'd argue it's the right amount of magic to help you with common patterns that you'd otherwise have to spend time manually implementing anyway (like the Dioxus Labs 'context' example).
How will it be implemented for types? I assume it would be derivable. Will it only be derivable, like Copy, or could you create an impl where claim does something different than clone?
How will backwards compatibility work? If this trait has to be explicitly implemented, then many existing user defined types that impl Copy and should be Claim will require a change to those types, and step 3 will break existing code for such existing types that are Copy but not Claim not getting captured by closures and async blocks. On the other hand if all Copy types are Claim, then there needs to be some way to opt out for large types (like the mentioned [u8; 1024]), and existing Copy types that shouldn't be Claim will be.
Then there are array types. The post says [u8; 1024] shouldn't be Claim. But what about smaller arrays? Should all array types be Copy but not Claim? If not, where is the cutoff, and does it depend on the element type?
One of the requirements is that the claim operation never panics. But that actually means Rc and Arc don't meet the requirements because they can panic if the reference count overflows. At least in theory. I'm not sure if that is practically possible on most hardware. It's certainly significantly less likely than failing to allocate.
Finally, how would the requirements be enforced? Would implementing this trait be unsafe for any non-Copy type? Or are these more like guidelines? Would (could?) the compiler enforce these requirements in the implementation of clone somehow?