Preserve imaginary zero signs when adding real values to complex numbers by moreal · Pull Request #7421 · RustPython/RustPython
291-303: Generic type parameter ordering is inconsistent with function parameter ordering.
The generic type parameters are declared as CCF, RCF, CRF, but the function parameters are ordered as cc_op, cr_op, rc_op. This mismatch is confusing—RCF (second generic) corresponds to rc_op (third parameter), while CRF (third generic) corresponds to cr_op (second parameter).
🔧 Suggested fix: reorder generic type parameters
- fn complex_real_binop<CCF, RCF, CRF, R>( + fn complex_real_binop<CCF, CRF, RCF, R>( a: &PyObject, b: &PyObject, cc_op: CCF, cr_op: CRF, rc_op: RCF, vm: &VirtualMachine, ) -> PyResult where CCF: FnOnce(Complex64, Complex64, &VirtualMachine) -> R, - CRF: FnOnce(Complex64, f64, &VirtualMachine) -> R, - RCF: FnOnce(f64, Complex64, &VirtualMachine) -> R, + CRF: FnOnce(Complex64, f64, &VirtualMachine) -> R, + RCF: FnOnce(f64, Complex64, &VirtualMachine) -> R, R: ToPyResult,
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@crates/vm/src/builtins/complex.rs` around lines 291 - 303, The generic type
parameter order in complex_real_binop is inconsistent with the function
parameter order; reorder the type parameters from CCF, RCF, CRF to CCF, CRF, RCF
so that CCF -> cc_op, CRF -> cr_op, and RCF -> rc_op (update the where-clause
and all uses of these type parameters in the signature accordingly).