TLDR: When generating code for ...Assign traits in std::ops with operands known to produce inconsistent-but-valid output types, how ought one to handle the output types to make it the least confusing?
Background:
A nice macro generates a general representation of a number. This representation includes coefficients of some numeric type T corresponding to the defining elements of some vector basis:
struct Number<T>(Vec<T>);
The macro also generates some Special utility types – essentially like sparse vectors on predetermined useful bases – like:
/// A special type with an a-coefficient
struct A<T>{ a: T }
/// A special type with a c-coefficient
struct C<T>{ c: T }
/// A special type with a d-coefficient
struct D<T>{ d: T }
/// A special type with a- and b-coefficients
struct AB<T>{ a: T, b: T }
/// A special type with a-, b- and c-coefficients
struct ABC<T>{ a: T, b: T, c: T }
// ..et. cetera
The nice macro also generates std::ops::Sub and std::ops::Add trait implementations by determining the associated Output types according to two rules:
1. When an in-basis coefficient is in the right-hand-side, the result is an instance of the left-hand-side specialized representation type:
AB<T> - A<T> = AB<T> // Basis: {a, b} + {a} = {a, b} ... can use same type
2. When an out-of-basis coefficient is in the right-hand-side, the result is a general representation type unless a known specialized type is exists matching the new basis:
AB<T> - C<T> = ABC<T>
// ^ Basis: {a,b} + {c} = {a,b,c} (basis matches another type)
AB<T> + D<T> = Number<T>
// ^ Basis: {a,b} + {d} = {a,b,c,d,...} (no basis-match, so use general type)
The Assign Problem
What should the nice macro do with the AddAssign and SubAssign traits?!
The solution above (using the general type for out-of-bounds basis operations) doesn't really work – obviously it can't change the type of the self being assigned to.
For now, it uses a nan-producing function to signify something wrong, but then, the basis behavior seems inconsistent:
AB<T> += D<T> -> AB::<T>::nan() // Basis: {a,b} += {d} ≠ {a,b}
Would it be less confusing to just not generate the ...Assign traits for these cases at all? I feel like this is a cop-out somehow. Or does this nan result help the user know they're writing code that attempts invalid operations?