Alternative Ergonomic Ref-counting RFC (github.com)
from SorteKanin@feddit.dk to rust@programming.dev on 22 Jul 12:02
https://feddit.dk/post/14320167

#rust

threaded - newest

BB_C@programming.dev on 22 Jul 12:56 next collapse

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 on 22 Jul 13:22 collapse

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.

orclev@lemmy.world on 22 Jul 14:50 collapse

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.