Compiling the following Rust code that uses operator overloading
use std::ops::{Add};
#[derive(Show)]
struct Point {
x: int,
y: int
}
impl Add for Point {
type Output = Point;
fn add(self, other: Point) -> Point {
Point {x: self.x + other.x, y: self.y + other.y}
}
}
fn main() {
let p: Point = Point {x: 1, y: 0};
let pp = p + p;
}
Results in compiler errors due to ownership of p:
<anon>:21:18: 21:19 error: use of moved value: `p`
<anon>:21 let pp = p + p;
^
<anon>:21:14: 21:15 note: `p` moved here because it has type `Point`, which is non-copyable
<anon>:21 let pp = p + p;
^
The rationale behind it is explained here and led to an RFC that was not accepted (part of due to reasons of the above example). However, later the following RFC still introduced the by-value type signatures for operators.
While I understand the rationale behind the decision. Due to my lack of experience in rust, I'm not sure what the "proper" way would be to allow the above code to work (a) if I do not want to copy or (b) how to make the struct copyable?
If you don't want to copy then, as far as my newbie understanding goes, you need to implement Add
on references to Point
.
This would be supported by the RFC:
Fortunately, there is no loss in expressiveness, since you can always implement the trait on reference types. However, for types that do need to be taken by reference, there is a slight loss in ergonomics since you may need to explicitly borrow the operands with &. The upside is that the ownership semantics become clearer: they more closely resemble normal function arguments.
And indeed it seems to work:
use std::ops::{Add};
#[derive(Show)]
struct Point {
x: i32,
y: i32
}
impl<'a> Add for &'a Point {
type Output = Point;
fn add(self, other: &'a Point) -> Point { //'
Point {x: self.x + other.x, y: self.y + other.y}
}
}
fn main() {
let p: Point = Point {x: 1, y: 0};
let pp = &p + &p;
println!("{:?}", pp);
}
(playpen)
To make Point
copyable instead, just replace #[derive(Show)]
with #[derive(Show,Copy)]
. Such structs used to be copyable by default, but it changed.
If your structure can't be copied (e.g. it has Drop
implementation, either itself or for one of its fields), then it may make sense to create several implementations: value+value, value+reference, reference+value and reference+reference. The first three can reuse the storage of one of the operands, and the last one can clone one of the operands and then just delegate to the already existing implementations. This way the user of your library can easily decide whether they want to reuse existing values for optimization or not.
In fact, that's how e.g. BigInt
or Complex
types are handled.
Your Point
, however, can just be made Copy
as it is cheap to copy it.
来源:https://stackoverflow.com/questions/27856991/operator-overloading-by-value-results-in-use-of-moved-value