Quote Originally Posted by jmcilhinney
Your constraints don't meet those requirements. Perhaps it would be convenient to be able to provide a list of types that the type argument must be one of, but generics do not support that.
Yeah, I just don't see why not. It will let you specify for classes & interfaces, but not specific structs or basic data types? Gimme a break. The compiler should be able to easily enforce that kind of type safety.

Quote Originally Posted by jmcilhinney
Generics just aren't going to do what you want to do. One class with overloaded methods would do the job.
It would do the job if you have huge amounts of computing power, yes. But efficiency is very high on the list of priorities for this project. It's not at all uncommon for the old, unmanaged version written in C & FORTRAN and hand-optimized to run for 10 minutes or more to do the computation. If this doesn't at least get somewhere in that ballpark, no one is going to pay it any attention. I'd probably sooner just give up on variable precision and go with double precision like the old one.

Oh, and since this is basically the foundation of the math libraries for the project, it wouldn't be one class that would need to be overloaded, it would more than likely be dozens. If you did manage it with one class or set of classes, it would be something bizarre like implementing INumber or some ugly work-around like that.

Though... sometimes things that should have been in the language are there, but buried in the CIL. Is there a way to modify the IL to make such a constraint on generic type parameters?