.NET generics & the .NET framework: not generic enough?

[Andreas Huber]

What follows is a discussion of my experience with .NET generics & the
..NET framework (as implemented in the Visual Studio 2005 Beta 1),
which leads to questions as to why certain things are the way they
are.

***** Summary & Questions *****

In a nutshell, the current .NET generics & .NET framework make it
sometimes difficult or even impossible to write truly generic code.
For example, it seems to be impossible to write a truly generic
Complex class or a truly generic Matrix class (see below for details).
Since this seems to be due to a combination of shortcomings in both
the .NET framework and the generics mechanism, I have two questions:

1. Why does the overload resolution mechanism only consider overloads
with generic parameters when we call a function with a generic
argument? If it considered other overloads as well, this would allow
us to work around classes that do not implement the proper generic
interfaces (see below for an example).

2. Why do .NET framework classes for primitive types (Byte, Int32,
Decimal, Double, etc.) not implement an interface like IArithmetic< T

(see below for an example)?
In isolation, neither of these limitations would be a big problem, as
we could easily work around them. However, their combination seems to
make it impossible to use generics for some tasks.

***** Discussion *****

Let us try to develop a generic Complex class in C# with generics. Our
(admitedly naive) first shot would be as follows:

public struct Complex< T >
{
T real;
T imag;

public Complex( T real, T imag )
{
this.real = real;
this.imag = imag;
}

public static Complex< T > operator +(
Complex< T > left, Complex< T > right )
{
return new Complex< T >(
left.real + right.real, left.imag + right.imag );
}

// other operators
}

Trying to compile this yields the following errors:

complex.cs(24,7 ): error CS0019: Operator '+' cannot be applied to
operands of type 'T' and 'T'
complex.cs(24,3 1): error CS0019: Operator '+' cannot be applied to
operands of type 'T' and 'T'

which is fair enough, as we didn't specify any constraints for T.
However, exactly what constraint should we specify to make this work?
After all we want to use our Complex class with primitive types (e.g.
float, double) *and* user-defined types. To make it usable for the
latter is easy enough:

public interface IArithmetic< T >
{
T Add( T other );
// other operations
}

public struct Complex< T > where T : IArithmetic< T >
{
T real;
T imag;

public Complex( T real, T imag )
{
this.real = real;
this.imag = imag;
}

public static Complex< T > operator +(
Complex< T > left, Complex< T > right )
{
return new Complex< T >(
left.real.Add( right.real ),
left.imag.Add( right.imag ) );
}

// other operators
}

So far so good, but what do we do to make this work for types that do
not implement our interface, namely framework-supplied ones like
float, double and perhaps decimal? All these types only implement the
interfaces IComparable, IFormattable, IConvertible and IComparable< T. None of these helps us implementing Complex. After some fiddling

around, I came up with the following:

public interface IArithmetic< T >
{
T Add( T other );
}

public struct Complex< T >
{
T real;
T imag;

public Complex( T real, T imag )
{
this.real = real;
this.imag = imag;
}

public static Complex< T > operator+(
Complex< T > left, Complex< T > right )
{
return new Complex< T >(
Add( left.real, right.real ),
Add( left.imag, right.imag ) );
}

// other operators

static float Add( float left, float right )
{
return left + right;
}

// other overloads for double, etc.

// overload for all other types
static U Add< U >( U left, U right )
{
// implementation postponed
}
}

I was hoping that the two Add overloads would allow me to discriminate
between primitive, framework-supplied types and user-supplied types.
This does not work, the generic overload is also selected when I add
two Complex< float > objects.
I then tried various other ways to discriminate between types, but
none of them led to anything more interesting than the above. It seems
that when you call a function with an argument of generic type that
the parameter of the function accepting said argument inevitably also
needs to be a generic type. I.e. the second Add overload can take two
forms:

static T Add( T left, T right )

or

static U Add< U >( U left, U right )

It seems that no matter which form we choose, no other Add overloads
(e.g. for float, etc.) will ever be considered.

[Daniel O'Connell [C# MVP]]

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:uA******** ******@TK2MSFTN GP10.phx.gbl...

Daniel,
Maybe its late ;-)

By the time I write all the dynamic methods for all the types I would
want,
wouldn't it be quicker or at least just as easy to simply write a code
generator based on the CodeDom to spit out all the Arithmetic proxy
classes
based on what I stated??

Probably, ;). Its all a matter of what you need and want to subject your
users to. Personally I'd take the approach that *doesn't* use extra
interfaces externally if possible. It'll confuse less people and put less
strain on existing OM's.

The only issue is, the CodeDom approach won't support extra types, the
dynamic methods approach will work with *all* types that support the
operator in question, even if they are written by the end user. CodeDom is a
bit tricky there.
Granted, the CodeDom approach gives you a nice way to constrain types.

It ends up being whichever best supports your needs.
Otherwise I'm keeping the code snippet it may come in handy for other
things...

Hopefully it will. Dynamic Methods are probably my favorite things about
..NET 2.0, ;).

[Jay B. Harlow [MVP - Outlook]]

Andreas,
If you haven't you may want to submit a suggestion at:

http://lab.msdn.microsoft.com/vs2005/

I see at least one suggestion:

http://lab.msdn.microsoft.com/produc...5-9c64cce45d2a

Related to this problem.

I was actually thinking of the Generic Delegate combined with an anonymous
method on possible the constructor...

Hope this helps
Jay
"Andreas Huber" <ah****@gmx.net > wrote in message
news:40******** **@news.bluewin .ch...

I sincerely hope you did not mean "really bad one" as bad as it
sounds. :-|
Sorry, that was not my intention. I didn't write "really bad" because I
think it's a bad idea to solve the problem this way (under the
circumstances, it might even be the best way). I wrote it because I had

high hopes that .NET generics will be a powerful tool to design our programs
better and avoid most of the code duplication that's currently necessary.
I'm a bit disappointed to see that I was hoping for too much. Generics do
solve a few problems (namely performance and compile-time correctness stuff) but they still only partially solve that nasty code duplication problem. I
also think the guys at Microsoft must be aware of this but they did not do
something about it. I'm sure they have their reasons but it would be nice to know them (including easy work-arounds we might be missing).

A second alternative I've wondered how usable would be Generic
Delegates,
only I'm not sure how easy they would be to use in this case.

Action<T> is an example of a generic delegate:

http://lab.msdn.micros oft.com/library/default.asp?url =/library/en-us/cpref/html/T_System_Action `1.asp
Generic delegates might indeed offer a way to specify how to perform the
operations of the generic type. But then again the same can be done with an interface:

interface IArithmeticOps< T >
{
T Add( T left, T right );
// other ops
}

struct Complex< T, Ops > where U : IArithmeticOps< T >, new()
{
static Ops ops = new Ops();
T real;
T imag;

// ...

public static T operator+( T left, T right )
{
return new Complex< T, Ops >(
ops.Add( left.real, right.real ),
ops.Add( left.imag, right.imag ) );
}
}

Regards,

Andreas

[Daniel O'Connell [C# MVP]]

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:Oo******** ******@TK2MSFTN GP12.phx.gbl...

Andreas,
If you haven't you may want to submit a suggestion at:

http://lab.msdn.microsoft.com/vs2005/

I see at least one suggestion:

http://lab.msdn.microsoft.com/produc...5-9c64cce45d2a

Unfortunatly that solution is pretty much *entirely* against the semantics
of C# as it stands today. Sadly, I think an entire virtual operator
implementation would have to be added to get this to work in any way nearing
clean.
Operators are rather complex things. Many suggetsions I see for adding
operator support are designed thinking that
Class<T> where T : operator+
is sufficent.

Its not. You need
Class<T> where T : T operator+(T,T)

at the minimum. And that *still* doesn't deal with issues like int and long,
which don't actually overload any operators.

This is really a situation where you are just screwed. IArithmetic would
probably be better. It doesn't require language changes across the board,
just a change to the system valuetypes, which can pretty much be done
without adding anything new to any language and it does so in a half way
sensible way with regard to existing language rules.

[Jay B. Harlow [MVP - Outlook]]

Daniel,
I gave the link more for an example of an existing suggestion, not as a
suggestion I specifically endorse.

I like IArithmetic<T>, as it seems to be the "easier" route. (the KISS
principal). If only Int32 implemented it ;-) also IArithmetic<T> is in
keeping with IComparable<T>.

I agree that an actual "operator +" constraint may need to get too fancy to
be useful, especially when you consider it needs to work across languages.
But then again Microsoft has a lot of talented people working for them, and
if we (the users) keep throwing it about in the publics, hopefully something
usable can be created...

Hopefully we can see something usable included in .NET 2.0 to allow generic
arithmetic...

Jay
"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2******** ********@tk2msf tngp13.phx.gbl. ..

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:Oo******** ******@TK2MSFTN GP12.phx.gbl...

Andreas,
If you haven't you may want to submit a suggestion at:

http://lab.msdn.microsoft.com/vs2005/

I see at least one suggestion:

http://lab.msdn.microsoft.com/produc...5-9c64cce45d2a
Unfortunatly that solution is pretty much *entirely* against the semantics
of C# as it stands today. Sadly, I think an entire virtual operator
implementation would have to be added to get this to work in any way nearing clean.
Operators are rather complex things. Many suggetsions I see for adding
operator support are designed thinking that
Class<T> where T : operator+
is sufficent.

Its not. You need
Class<T> where T : T operator+(T,T)

at the minimum. And that *still* doesn't deal with issues like int and long, which don't actually overload any operators.

This is really a situation where you are just screwed. IArithmetic would
probably be better. It doesn't require language changes across the board,
just a change to the system valuetypes, which can pretty much be done
without adding anything new to any language and it does so in a half way
sensible way with regard to existing language rules.

[Daniel O'Connell [C# MVP]]

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

Daniel,
I gave the link more for an example of an existing suggestion, not as a
suggestion I specifically endorse.

Sorry, I didn't mean to be harsh. I'm just rather annoyed with the operator
thing. I think I've posted that same general reply a dozen times now.
I like IArithmetic<T>, as it seems to be the "easier" route. (the KISS
principal). If only Int32 implemented it ;-) also IArithmetic<T> is in
keeping with IComparable<T>. Ya, that would help termendously by helping to constrain generics to
primatives alone. I do wish there was a way to express that you want int,
uint, byte, sbyte, short, ushort, long, ulong, string, decimal, double or
float *only* in a generic. It'd help out *alot* in data situations where you
want to create classes that handle simple data. But, alas, that is a pipe
dream right now. IArithmetic wouldn't help with everything, but it'd make
numbers simpler.

I agree that an actual "operator +" constraint may need to get too fancy
to
be useful, especially when you consider it needs to work across languages.
But then again Microsoft has a lot of talented people working for them,
and
if we (the users) keep throwing it about in the publics, hopefully
something
usable can be created...

Well, I for one am not a huge fan of operator overloading in general, but it
is frustrating not to be able to perform basic mathematics with generics. It
certainly takes away the ability to *easily* do something like the stream in
STL, where the size type could be defined in the template.

[Mattias Sjögren]

I've found when I use IComparable<T> for a value type (System.Int32 for
example), there is no boxing going on, why would IArithmetic<T> cause boxing
to go on?
Right, it shouldn't, by bad. Casting to the interfce still causes
boxing, but there shouldn't be any need for the cast if the constraint
is there.

I agree true operator constraints would probably be the best, Not entirely
sure how they would work as + on Int32 is a IL opcode, while + on
System.Decim al is an overloaded operator, would an operator contraint
require an overloaded operator, requiring Int32 to offer the overloaded
operators, although + for Int32 is already an IL opcode?
I don't know how they'd implement it. The compilers might have to
special-case the primitive types.

Either way, the JIT better be darn good at recognizing the IL sequence
and effectively produce the same native code as a simple add
instruction for primitive types, or the overhead of the method call
would hurt performance. The same is true for IArithmetic methods of
course.

My only concern with IArithmetic<T> is should there be a single interface
with all math "operators" , or should there be individual interfaces, such as
IAdd<T>, ISubtract<T>, IMultiply<T>, IDivide<T>, and so on that
IArithmetic< T> inherits from? As I can see creating generic classes that
need to support addition but (TimeSpan) but Multiplication does not make
sense...

Yes that's definitely a problem too. A single interface with all the
operations is not granular enough, and wouldn't give you compile time
checking of which methods are actually supported.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Jay B. Harlow [MVP - Outlook]]

Daniel,

primatives alone. I do wish there was a way to express that you want int,
uint, byte, sbyte, short, ushort, long, ulong, string, decimal, double or
float *only* in a generic Why? What if I create a BetterInt32? (aka a family of types like SqlInt32 in
System.Data.Sql Types) that due to CLS requirements BetterInt32 cannot be a
generic class, so I need to do it the "old fashion way". Remember that
Generics are not CLS compatible, however you are free to use generics
internal to your project, even if the public interface is CLS compatible.

Why should generic math be limited to Int32 and not my BetterInt32?

Also as I mentioned elsewhere in this thread. int uses an IL opcode for
addition, while decimal uses an overloaded operator, so you have an
exception from the start, so enabling a constraint for just the "primitives "
is probably more work then it needs to be or should be, as it would need to
support both overloaded operators & opcodes...

One of the reasons for struct & overloaded operators is to enable us as
designers to define our own "simple data". For example Martin Fowler's
Range & Quantity patterns, both of which I would consider "simple data", and
I could see a need to enable them for generic math!

http://www.martinfowler.com/ap2/

http://martinfowler.com/ieeeSoftware/whenType.pdf

Just a thought
Jay

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:OA******** ********@TK2MSF TNGP10.phx.gbl. ..
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

Daniel,
I gave the link more for an example of an existing suggestion, not as a
suggestion I specifically endorse.

Sorry, I didn't mean to be harsh. I'm just rather annoyed with the

operator thing. I think I've posted that same general reply a dozen times now.

I like IArithmetic<T>, as it seems to be the "easier" route. (the KISS
principal). If only Int32 implemented it ;-) also IArithmetic<T> is in
keeping with IComparable<T>. Ya, that would help termendously by helping to constrain generics to
primatives alone. I do wish there was a way to express that you want int,
uint, byte, sbyte, short, ushort, long, ulong, string, decimal, double or
float *only* in a generic. It'd help out *alot* in data situations where

you want to create classes that handle simple data. But, alas, that is a pipe
dream right now. IArithmetic wouldn't help with everything, but it'd make
numbers simpler.

I agree that an actual "operator +" constraint may need to get too fancy
to
be useful, especially when you consider it needs to work across languages. But then again Microsoft has a lot of talented people working for them,
and
if we (the users) keep throwing it about in the publics, hopefully
something
usable can be created...
Well, I for one am not a huge fan of operator overloading in general, but

it is frustrating not to be able to perform basic mathematics with generics. It certainly takes away the ability to *easily* do something like the stream in STL, where the size type could be defined in the template.

[Daniel O'Connell [C# MVP]]

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:eV******** ******@TK2MSFTN GP09.phx.gbl...

Daniel,

primatives alone. I do wish there was a way to express that you want
int,
uint, byte, sbyte, short, ushort, long, ulong, string, decimal, double or
float *only* in a generic Why? What if I create a BetterInt32? (aka a family of types like SqlInt32
in
System.Data.Sql Types) that due to CLS requirements BetterInt32 cannot be a
generic class, so I need to do it the "old fashion way". Remember that
Generics are not CLS compatible, however you are free to use generics
internal to your project, even if the public interface is CLS compatible.

Why should generic math be limited to Int32 and not my BetterInt32?

I didn't *say* generic math. I said data. I write quite a few classes that
have to deal with simple data and often that data has to be interconverted
or expressed in an exceedingly simple type systems(no lists, no currency, no
custom value types, etc). I use IConvertible now and do my best to convert
bad types into valid ones, but its not the most reliable and clear method
possible.

Infact one of those links makes the point" "If you have a method that
expects to take a currency parameter, you can communicate this more clearly
by having a currency type and using it in the method declaration". I would
say it would follow that if your method cannot take BetterInt32, it isn't a
good idea to *allow* that method to take a BetterInt32, wouldn't you? Hence
a need to constrain to primative types when only primative types work.
Also as I mentioned elsewhere in this thread. int uses an IL opcode for
addition, while decimal uses an overloaded operator, so you have an
exception from the start, so enabling a constraint for just the
"primitives "
is probably more work then it needs to be or should be, as it would need
to
support both overloaded operators & opcodes...

One of the reasons for struct & overloaded operators is to enable us as
designers to define our own "simple data". For example Martin Fowler's
Range & Quantity patterns, both of which I would consider "simple data",
and
I could see a need to enable them for generic math!

http://www.martinfowler.com/ap2/

http://martinfowler.com/ieeeSoftware/whenType.pdf

Just a thought
Jay

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:OA******** ********@TK2MSF TNGP10.phx.gbl. ..

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

> Daniel,
> I gave the link more for an example of an existing suggestion, not as a
> suggestion I specifically endorse.
>

Sorry, I didn't mean to be harsh. I'm just rather annoyed with the

operator

thing. I think I've posted that same general reply a dozen times now.

> I like IArithmetic<T>, as it seems to be the "easier" route. (the KISS
> principal). If only Int32 implemented it ;-) also IArithmetic<T> is in
> keeping with IComparable<T>.

Ya, that would help termendously by helping to constrain generics to
primatives alone. I do wish there was a way to express that you want
int,
uint, byte, sbyte, short, ushort, long, ulong, string, decimal, double or
float *only* in a generic. It'd help out *alot* in data situations where

you

want to create classes that handle simple data. But, alas, that is a pipe
dream right now. IArithmetic wouldn't help with everything, but it'd make
numbers simpler.

>
> I agree that an actual "operator +" constraint may need to get too
> fancy
> to
> be useful, especially when you consider it needs to work across languages. > But then again Microsoft has a lot of talented people working for them,
> and
> if we (the users) keep throwing it about in the publics, hopefully
> something
> usable can be created...
>

Well, I for one am not a huge fan of operator overloading in general, but

it

is frustrating not to be able to perform basic mathematics with generics.

It

certainly takes away the ability to *easily* do something like the stream

in

STL, where the size type could be defined in the template.