is there a reason why the numeric types don't implement an interface that
defined the operators for math as required?
A number of such have been proposed (as discussion points on forums
like this), but they all suffer from the fact that our current
understanding of operators is much more flexible than a standard
interface would permit. Often there are operators against a range of
different types with different outputs, so the signatures of the
methods would be tricky - it isn't always T with "T Operator(T arg)".
The nature of maths is an issue too - the operations supported by
different number systems are not consistent; "uint", for instance,
doesn't define "negate" (additive inverse). Likewise the int-based
numbers don't define "reciprocol " (multiplicative inverse), nor do non-
square matrices. Division is better supported, but still has issues.
This means that either you'd have a ridiculous number of (probably
generic) interfaces (with 1, maybe 2 methods each), or you'd have a
few interfaces (with lots of simple T=>T methods) where you already
know that some methods are reasonably likely to throw "NotSupport ed"
or "InvalidOperati on" (because they simply don't make sense for that
number system).
The first option (lots of interfaces) becomes very restrictive and
almost impossible to use; the second (untrustworthy interfaces)
doesn't buy an awful lot of *true* safety anyway.
Thus I propose that the duck-typing (to borrow Jon's usage) is
certainly no worse than anything else we can currently propose; but it
works, exists today, and is as quick as you'd like.
For completeness, I have also seen a previous reply on this subject
that the number of interfaces, members, virtcalls, etc (against the
primatives) would have a significant impact on things like CF. I don't
know about the truth of this claim, however.
Marc