Can you elaborate a bit more on why/how exactly did the earlier language design (implicitly clone by default if it's absolutely necessary and otherwise move, instead of move by default) result in much more cloning? Because intuitively it seems to me that if you try to use data that has been moved away, then it means that you didn't intend to move the data away in the first place, but to clone it. And vice versa.
On 2014-06-12, at 21:15, Patrick Walton <[email protected]> wrote: > On 6/12/14 11:15 AM, Tommi wrote: >> On 2014-06-12, at 20:59, Corey Richardson <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Implicit cloning is a non-starter. Clones can be very expensive. >>> Hiding that cost is undesirable and would require adding Clone to the >>> language (it's currently a normal library feature). >> >> But I think it will be easy to make the error of writing the explicit >> .clone() in places where it's not needed. For example: >> >> fn foo<T>(value: T) {} >> >> let x = box 123; >> x.clone().foo(); >> x.clone().foo(); >> >> ...given that `x` is not used after those lines, the last call to >> .clone() is unnecessary. Whereas, if the task of cloning (implicitly) is >> assigned to the compiler, then the compiler can use static analysis to >> make sure such programming errors never occur. The example above would >> become something like: >> >> fn foo<T>(stable value: T) {} >> >> let x = box 123; >> x.foo(); // here `x` gets cloned here >> x.foo(); // here `x` doesn't get cloned because this is the last use of `x` > > We tried that in earlier versions of Rust. There were way too many clones. > > Patrick > _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
