Question

I am working in a small educational project where we have to implement a n-dimensional matrix. Depending on the context, this matrix has either to work with our own built-in ComplexNumber struct or with System.Double and for very simple examples, with integral types (mainly System.Int32).

Due to the nature of the application, we are not demanded to implement lightning fast performance.

My first idea was therefore to implement a Matrix<T> where T would somehow need to be restricted to “numbers”.

The obvious problem in doing this is that there is no way right now in the language to constraint the generic type T with defined operators. Also I do not see an easy way to restrcit T to reasonable types.

My questions are:

1. Can somebody please point me in the direction of an elegant way to make mathematical operations with generic types that doesn’t compromise performance too much and to somehow make that work with built in types (if possible).

2. If Eric ever reads this, does this feature (constraining generic types by defined operators) ever come up in hypothetical future versions of C# design meetings and has it ever been close to making it into the language?

I know its easier and better to implement a ComplexMatrix type and create wrappers around it for each matrix “sub-type” (double, integral, etc.) and pay the performance costs of the conversions between our complex type and whichever type the matrix elements happen to be. This question is more out of curiousity on how would someone implement a similar scenario.

Answer 1

If Eric ever reads this,

If you want something brought to my attention, try the contact link on my blog. Or put my full name in the text of the question so that me searching for myself will find me.

does this feature (constraining generic types by defined operators) ever come up in hypothetical future versions of C# design meetings and has it ever been close to making it into the language?

Indeed, this is a frequently requested feature. We’ve been getting requests for this sort of thing since C# 1.0.

The feature would requires support from the CLR team, not just the language — it is the sort of feature that we would want to integrate into all our languages, which increases the cost.

The CLR team has expressed interest in features like this, but they also have a lot of competing features that they could be doing, and limited time and effort to implement those features.

There are numerous ways such a feature could be implemented. For example, we could add the ability to specify static methods in interfaces:

interface IAddable<T>
{
    static T operator+(T x, T y);
}

and then

static T Sum<T>(IEnumerable<T> seq) where T : IAddable<T>
{
    T sum = default(T);
    foreach(T item in seq) sum = sum + item;
    return sum;
}    

The idea would be that the interface means “a type that implements this interface must have the given static methods”. We’d then make int automatically implement IAddable<int>, and so on.

How do do so efficiently in a world with runtime-generated generic code is an open question.

I hasten to add that this is just a sketch of an idea. There are many ways to implement this sort of feature. The “statics in interfaces” idea is one that has broader usage than just mathematics, and that’s attractive to us. If we’re going to go to the huge expense of this sort of feature, it would be nice to have a really general, powerful feature rather than one narrowly focussed on math.

On the other hand, the perfect is the enemy of the good; it might be better to just concentrate on the math problem and not go for a more expensive general solution.

It’s an ongoing debate. It is definitely on everyone’s radar screen, but I would not expect it any time soon. The language designers are all heads-down working on going through the feedback from the async CTP.

As always, Eric’s musings about hypothetical future language features of hypothetical unannounced future products are for entertainment purposes only.