Igualdad y orden: por qué el float solo es PartialOrd

Comparar con == y ordenar con < parecen operaciones triviales hasta que aparece el NaN, el “no es un número” de los flotantes, que no es igual ni a sí mismo. Rust se toma esa anomalía en serio y reparte la comparación en cuatro traits en dos niveles: PartialEq y PartialOrd, que admiten huecos, y sus sellos Eq y Ord, que prometen que no hay ninguno. El resultado es que f64 puede compararse, pero honestamente se queda en la familia Partial. Ese detalle, que parece pedante, es el sistema de tipos negándose a mentir sobre las matemáticas.

Igualdad: PartialEq y el sello Eq

PartialEq habilita == y !=. Se deriva y compara campo a campo:

#[derive(PartialEq)]
struct Version {
    mayor: u32,
    menor: u32,
}

fn main() {
    let a = Version { mayor: 1, menor: 4 };
    let b = Version { mayor: 1, menor: 4 };
    assert!(a == b);   // igual campo a campo
}

Eq es un trait marcador: no añade ni un método sobre PartialEq. Lo que aporta es una promesa matemática: que la igualdad es reflexiva, es decir, que a == a es verdad para todo valor a. Con PartialEq a secas tienes solo simetría (a == b implica b == a) y transitividad; Eq añade la reflexividad que faltaba para tener una relación de equivalencia completa.

Orden: PartialOrd y el sello Ord

PartialOrd habilita <, >, <= y >=. Su método clave es partial_cmp, que devuelve Option<Ordering>: un Some(Less | Equal | Greater) cuando los valores son comparables, o None cuando no lo son. Ese Option es la puerta por la que entran los huecos.

Ord es el sello que promete que no hay huecos: su método cmp devuelve un Ordering directo, sin Option, porque garantiza un orden total: dos valores cualesquiera siempre son comparables y hay un ganador (o son iguales). Ord requiere Eq y PartialOrd, porque un orden total presupone una igualdad total.

#[derive(PartialEq, Eq, PartialOrd, Ord)]
struct Prioridad(u8);

fn main() {
    let mut v = vec![Prioridad(3), Prioridad(1), Prioridad(2)];
    v.sort();   // sort() EXIGE Ord: necesita un orden total
}

flowchart TD
PE[PartialEq da doble igual] -->|sello reflexividad| EQ[Eq igualdad total]
PO[PartialOrd da menor y mayor con Option] -->|sello sin huecos| OR[Ord orden total]
EQ --> OR
PO -.requiere.-> PE
OR --> USO[Claves de BTreeMap y metodo sort]
EQ --> USH[Claves de HashMap con Hash]
style PE fill:#89b4fa,color:#11111b
style PO fill:#89b4fa,color:#11111b
style EQ fill:#a6e3a1,color:#11111b
style OR fill:#a6e3a1,color:#11111b

Por qué el float solo es PartialOrd

Los flotantes de la norma IEEE-754 tienen un valor especial, NaN (not a number), que aparece en operaciones como 0.0 / 0.0. La norma dicta que NaN no es igual a nada, ni siquiera a sí mismo:

fn main() {
    let nan = f64::NAN;
    assert!(nan != nan);              // NaN nunca es igual a si mismo
    assert!(!(1.0 < nan));            // toda comparacion con NaN es falsa
    assert!(!(1.0 > nan));            // ni menor, ni mayor, ni igual: incomparable
    assert_eq!(nan.partial_cmp(&1.0), None); // partial_cmp lo confiesa con None
}

Esto rompe las dos promesas de golpe. La reflexividad de Eq falla, porque nan == nan es falso: por eso f64 implementa PartialEq pero no Eq. Y la totalidad de Ord falla, porque NaN es incomparable con cualquier número —partial_cmp devuelve None—: por eso f64 implementa PartialOrd pero no Ord.

La consecuencia es concreta y a veces frustrante: no puedes usar un f64 como clave de un HashMap (necesita Eq) ni ordenar un Vec<f64> con .sort() (necesita Ord). Rust no te lo prohíbe por capricho: te está impidiendo construir una tabla hash sobre una igualdad rota o un orden sobre una relación con agujeros, dos bugs silenciosos que casi cualquier otro lenguaje te dejaría cometer.

Las leyes que tú garantizas

Eq y Ord no añaden métodos: son marcadores de leyes. Cuando derivas, la mecánica campo a campo las respeta por construcción. Pero si implementas PartialEq u Ord a mano, eres tú quien promete que se cumplen —reflexividad, simetría, transitividad, totalidad— y nadie lo verifica. Romperlas no es undefined behavior, pero sí un bug lógico venenoso: un Ord inconsistente hace que un BTreeMap pierda elementos o entregue resultados absurdos, y un PartialEq no simétrico corrompe cualquier búsqueda.

Un detalle del derive que hay que interiorizar: compara campo a campo en el orden de declaración. El primer campo manda; los siguientes solo desempatan. Reordenar los campos de un struct con #[derive(Ord)] cambia su orden, aunque los datos sean los mismos.

#[derive(PartialEq, Eq, PartialOrd, Ord, Debug)]
struct Semver {
    mayor: u32,   // se compara primero
    menor: u32,   // solo desempata si 'mayor' coincide
    parche: u32,  // solo desempata si 'mayor' y 'menor' coinciden
}

#[derive(PartialEq, Eq, PartialOrd, Ord, Debug)]
enum Severidad {
    Info,   // la menor
    Aviso,
    Error,  // la mayor
}