On 19/07/13 05:39, Corey Richardson wrote:
On Thu, Jul 18, 2013 at 3:33 PM, Daniel Micay <[email protected]> wrote:
Plenty of types can't actually be ordered, and in *many* cases not all
fields should be considered for equality/ordering and they may or may
not be listed in the order the comparison should try.
I've wanted like #[deriving(Ord(a, b), Eq(b, c))] which would define
not only which fields are used for comparison but also the order of
the fields for... ordering.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
I'm working on this; at the moment the plan is to look something like:
#[deriving(Ord(test_order(z,y),
reverse(y),
ignore(w)))]
struct A { x: int, y: int, z: int, w: int, t: int }
// is the same as
impl Ord for A {
fn lt(&self, other: &A) -> bool {
self.z < other.z &&
other.y < self.y &&
self.x < other.x &&
self.t < other.t
}
// etc.
}
The reason `test_order` and `ignore` are separated is because I imagine
the most common cases are ignoring one field, and moving one field to be
tested first, and so these would be #[deriving(Ord(ignore(field)))] and
#[deriving(Ord(test_order(field)))] respectively, rather than having
to list all the fields explicitly. (I'm willing to be convinced
otherwise.)
It will work with `Eq`, `TotalEq` and `TotalOrd` too; and for each trait
the appropriate options (i.e. `ignore` for the Total traits, and `reverse`
for the Eq ones) will be disabled with an error.
Huon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
