this post was submitted on 22 Jul 2025
20 points (100.0% liked)

Rust

7183 readers
1 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 2 years ago
MODERATORS
top 3 comments
sorted by: hot top controversial new old
[–] orclev@lemmy.world 6 points 4 days ago* (last edited 4 days ago)

My initial thought on this is that it's treating a symptom not the problem. Ultimately I think the mistake was overloading 'clone()' for Rc and Arc types. Semantically clone implies memory being duplicated, but when you clone an Rc or Arc that isn't what you're doing. You are in fact explicitly not copying memory which is the entire point. If you think of clone as semantically equivalent to malloc I think the problem becomes more apparent. Had they introduced a new trait and method for "cheaply copyable types" like Rc and Arc we wouldn't have this problem as the compiler could trivially work out anywhere it could make copies. In short there's a need for a trait that sits in between Clone and Copy. Heavier than a Copy, but significantly lighter than a Clone.

Edit: thinking a little more semantically this equates to: Copy types can be duplicated without using an allocator simply by copying bits as is. Clone types require an allocator to copy and a method call to perform book keeping. This new trait can be duplicated without an allocator but does require a method call to perform book keeping.

[–] BB_C@programming.dev 5 points 4 days ago (1 children)

As someone who hasn't been following this, playing the connotation game (using "automatic" instead [partially] "implicit") is rubbing me the wrong way.

Otherwise, the keyword use seems too generic to be used for this. But I'm sure this has been bikeshedded already, and if it hasn't, it will be.

[–] balsoft@lemmy.ml 5 points 4 days ago* (last edited 4 days ago)

Otherwise, the keyword use seems too generic to be used for this

I also feel that way, and I don't even understand how the word "use" is related to the underlying semantics at all.

My only guess is that use is already a keyword, and anything that's not a keyword currently would require a new language edition. I would also prefer something like autoclone async {}, or maybe even with_cloned <explicit list of objects to clone, or _ for automatic detection> async {} . Not sure if it 100% makes sense but would be more readable IMO.

P.S. it seems they will explore an alternative solution that doesn't involve a new keyword at all, and just automagically clones when it's "cheap" to do. Sounds more user-friendly to me TBH.