TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Claiming, Auto and Otherwise

5 pointsby royjacobs11 months ago

2 comments

thayne11 months ago
I generally like the idea, but I have some questions that weren&#x27;t addressed:<p>How will it be implemented for types? I assume it would be derivable. Will it <i>only</i> be derivable, like Copy, or could you create an impl where claim does something different than clone?<p>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&#x27;t be Claim will be.<p>Then there are array types. The post says [u8; 1024] shouldn&#x27;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?<p>One of the requirements is that the claim operation never panics. But that actually means Rc and Arc don&#x27;t meet the requirements because they <i>can</i> panic if the reference count overflows. At least in theory. I&#x27;m not sure if that is practically possible on most hardware. It&#x27;s certainly significantly less likely than failing to allocate.<p>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?
评论 #40758453 未加载
royjacobs11 months ago
I really like this proposal. It&#x27;s fairly concrete, makes day-to-day coding much more ergonomic and, more importantly, doesn&#x27;t introduce a great many esoteric concepts that are just going to clutter the language.<p>I&#x27;m assuming not everyone will agree with this, since it&#x27;s more &#x27;magic&#x27; but I&#x27;d argue it&#x27;s the right amount of magic to help you with common patterns that you&#x27;d otherwise have to spend time manually implementing anyway (like the Dioxus Labs &#x27;context&#x27; example).