there is currently a lot of ongoing discussions about "easier light weight clones" not just in the context of the RFC but in general. And from all the discussi

there is currently a lot of ongoing discussions about "easier light weight clones" not just in the context of the RFC but in general. And from all the discussions I have seen this RFC is one of the less promising ones as it mixes up the concept of "implicitly doing an operation before moving something into a closure scope" and "light weight clones" in a confusing ambiguous way. So I don't expect it to be accepted/implemented this way, but I expect something similar to happen. Like for "light weight clones" use is a pretty bad name and new syntax isn't needed, if we start shortening a `.clone()` to `.use` because it saves 4 letters then we are doing something wrong. Similar if argue for it for niche optimization reasons instead of improving generic optimizations to have the same outcome we are doing something wrong IMHO. And for the the scoping/closure aspect (i.e. a rust equivalent of C++ closures `[]` parts (e.g. [&x](){...}) then it also seems a bad solution. First it's a operation which relates to the closure scope not the call inside of it, so attaching it to the call inside of it isn't a grate idea. Especially given that you might have multiple places you pass a clone of x in and this leading to a lot of ambiguity not highlighted with any examples in the RFC. Secondly for this concept it isn't limited to "cheap clones" sometimes you have the same pattern for not-so-cheap clones (through it mainly matters for cheap clones). And lastly if we really add ways to define captures, why not allow defining captures. Now sure if you have a good solution for more compact way to handle "not-copy but still cheap" sharing (cloning of handles/smart pointers) of values there it maybe could make sense to also allow it to happen implicitly outside of closure capture scope instead of the invocation scope. But I would argue it's an extension of an not yet existing handle/smart pointer ergonomic improvement and should be done after that improvement. (yes, I'm aware they use `use` because it's already a keyword, but making a non-zero cost copy of a handle/smart pointer isn't exactly "use it" but more like "share it" :/)