Moved ret value reused after match consumption

High Severity

NumOpResult does not derive Copy, so match ret in the else branch moves ret. The code then attempts to return ret on line 243 after the if/else, which is a use-after-move. In the else path (promotion case), ret is consumed by the match to extract the value for num1_slice.insert(...), and is no longer available as the arm's return value. This affects every integer type variant expanded by the macro.

 

You are wrong, the inner value of ret impl Copy so its ok

Bug: Use-after-move on ret

NumOpResult does not derive Copy (it can't, because INumber is not Copy). The match ret { ... } in the else branch moves ret, but then ret is used as the return value after the if/else block on line 243. Rust's borrow checker considers all branches — since ret is potentially moved in the else path, it's unavailable after the if/else. This should be a compile error.

The fact that i64/u64 inner values are Copy doesn't help — the outer enum is still consumed by the match.

Suggested fix: Match on a reference instead:

match &ret {
    NumOpResult::I64(v) => num1_slice.insert(index, *v)?,
    NumOpResult::U64(v) => num1_slice.insert(index, *v)?,
    _ => unreachable!(),
}

This borrows ret rather than consuming it, so ret remains available for the return on line 243.

Again, read the comments above

Behavioral change: Return value no longer reflects stored precision

Previously, the half-float and float paths returned the value as stored (after narrowing to $hf_type/$f_type), reflecting the actual precision loss:

// Old half-float:
*num1 = <$hf_type>::from_f64(new_val);
Ok(NumOpResult::F64(f64::from(*num1)))  // returned the narrowed value

// Old float:
*num1 = new_val as $f_type;
Ok(NumOpResult::F64(*num1 as f64))      // returned the narrowed value

Now both paths return NumOpResult::F64(new_val) — the full f64 result, even when the stored value was narrowed to fit.

This means for non-promotion cases (where the value fits in f16/f32), the command returns a different value than what's actually stored. For example, an operation on an f16 array might return 1.000976... but actually store 1.0 in f16 precision.

Is this change intentional? If the goal is to always return the "mathematically correct" result regardless of storage precision, that's a valid design choice — but it should be documented. If not, consider returning f64::from(*num1) in the if narrowed.is_finite() branch (when the value fits without promotion).