Principles of Program Analysis

Generics in C# - The good, the bad & the ugly

Author Supervisors Technical Adviser
Lukas Kretschmar Prof. Dr. Josef M. Joller Thomas Corbat
lukas.kretschmar@hsr.ch Prof. Peter Sommerlad
University of Applied Sciences Rapperswil
Seminar Report, June 5, 2015

Abstract
Generics - some like them, some hate them, some have mastered their usage, some get ambushed
by compiler errors and some just dont use them for whatever reason. Even though the concept of
Generics, and in a broader view Generic Programming, is out there some years, even decades, there
exist still developers that have never heard of Generics or struggle with Type Parameters.
In this paper we provide a broad summary on Generics in C#. At first, we present their current
capabilities. These are the parts that are mostly mentioned in books giving an introduction on the
programming language.
Based on the known capabilities, we show what Generics cant do, respectively where the limitations
are. And at the end, we go one step further, presenting solutions to circumvent some limitations,
mention unexpected pitfalls and other ugly parts. They are normally not mentioned when Generics
are introduced and are the main reason why some cant stand Generics.

Keywords: Generics, Parametrized Types, Generic Programming, C#, Java, C++

1
1 INTRODUCTION

Contents often than others, some too many times than pre-
ferred. There are many root causes for the vio-
1 Introduction 2 lation of the DRY (dont repeat yourself) princi-
1.1 Related work . . . . . . . . . . . . 2 ple [36]. But most likely, it is one of the following:
1.2 Overview . . . . . . . . . . . . . . 3
Copy & paste
2 Generic Programming and Parame-
terized Types 3 Very similar functionality

3 The Good 3 Generated code

3.1 Implementation of Generics . . . . 3
3.2 Type Constraints . . . . . . . . . . 5 The latter is sometimes not avoidable due to the
3.2.1 class & struct . . . . . . . . 5 lack of configurability of the generator but in a
3.2.2 Inheritance & Interfaces . . 7 way not that bad since it is managed through the
3.2.3 new() . . . . . . . . . . . . 7 generator and could be easily regenerated.
3.3 Co- & Contravariance . . . . . . . 8 Similar functionality is maybe not seen by the
3.3.1 Covariance . . . . . . . . . 8 developer in the first place, and needs to be refac-
3.3.2 Contravariance . . . . . . . 8 tored to a point where the code duplication is ob-
vious. And copy & paste duplication is obviously
4 The Bad 9 duplicated.
4.1 Generic Properties . . . . . . . . . 9 Anyway, chances are high if we encounter du-
4.2 Type Constraints . . . . . . . . . . 9 plicated code, only the used types will differ. And
4.3 Unusable superclasses . . . . . . . 10 if this is the case, using some sort of Generic Pro-
4.3.1 Enums . . . . . . . . . . . . 10 gramming [43], in our case Generics, is the best
4.3.2 Nullable Types . . . . . . . 10 way to go. Generics are a concrete application of
Parameterized Types, or subset of Generic Pro-
4.3.3 new() . . . . . . . . . . . . 11
gramming, in C#, Java and other programming
4.4 Co- & Contravariance . . . . . . . 12
languages.
4.4.1 Variance when defined . . . 12
4.4.2 Variance only on interfaces 13
1.1 Related work
5 The Ugly 13
5.1 Generics and static . . . . . . . . . 13 The idea of Parameterized Types is out there for
5.2 Operator overloading . . . . . . . . 15 years and has its origins in a paper published in
5.2.1 Operator inheritance . . . . 16 1989 by Musser and Stepanov defining the term
5.2.2 Using dynamic . . . . . . . 17 Generic Programming [43]. A refined paper was
5.3 Stacking Type Parameters . . . . . 18 then published later on [27].
Regarding Generics in C#, some publications
6 Conclusion 18 were done by Kennedy et al ( [39], [40], [38],
[41], [37]) of Microsoft Research Cambridge [17].
A Domain model 23 While these papers focus on concrete capabilities
and implementations, there exist some more for-
mal definitions how Generics in C# can be speci-
fied ( [48], [29]).
There has also been done some work by Gar-
cia et al [33], comparing the different approaches
1 Introduction how Parameterized Types are supported in C#,
Java, and C++. But this was done before C# and
Every software engineer stumbles from time to Java officially supported Generics. A newer com-
time over duplicated code, probably the most parison of the different implementations on Pa-
common code smell [30] out there. Some more rameterized Types was done by Giovannelli [35].

2
1.2 Overview
In this paper we are going to have a look at
Generics in C# [4], their implementation and
their capabilities especially focusing on the limi-
tations and unsound properties. Where appropri-
ate, we will compare the situation with Generics
in Java [5] or Templates in C++ [3].
We know, Templates are not directly compara-
ble with Generics. But since both concepts (not
to be confused with C++ -concepts [28]) are ap-
plications of Parameterized Types in their lan-
guages we find it appropriate to mention their
commonalities and differences.
The paper is structured as follows: In section
2, we give a brief introduction on Generic Pro-
gramming. In section 3, we have a look at the
implementation of Parameterized Types in the
CLI and mention the capabilities of Generics in
C#. Their limitations are mentioned in section
4, followed by possible pitfalls in section 5. And
finally, in section 6, we reflect on our findings.
Since the capabilities of Generics are normally
covered by books on C# (e.g. [46] or [26]), we fo-
cus on sections 4 and 5.
An overview of the used classes, in terms of
their dependencies, is attached to appendix A.
We take the liberty to simplify code examples
and omit unnecessary details (e.g. if a modifier
is missing, assume public, with the exception of
fields, where we assume private).
2 Generic Programming and
Parameterized Types
Generic Programming [43] paraphrases the
ability to write code in a way it is usable with
different types that just provide at least the in-
terface the code expects. How this interface is
guaranteed may vary among the different used
approaches to support Generic Programming.
We differentiate between two possibilities:
Implicitly
Explicitly
Implicitly means the interface is derived by the
used capabilities within the code as it is the case
3
in C++. In this case, it is not necessary that
an interface must be declared (as we are used
to if using C# or Java) and shared among types.
Hence types are not forced to have a common
supertype or implement the same interface. A
type that is used with the Generic code just has
to offer the expected capabilities.
Explicitly requires that the interface must be
declared for the given code at first, as it is the
case in C# and Java. And there are also some
developments in C++ to introduce explicit inter-
face requirements ( [28], [47]).
Parameterized Types are types that use
placeholders for types, called Type Parameters,
when defined. The specific types of the place-
holders are unknown until the Parameterized
Type is used. With respect to the languages used
in this paper, we define Parameterized Types
with
C<T [, U ] >
where C denotes the class, T the first Type Pa-
rameter and [, U ] any additional Type Parame-
ter.
3 The Good
In this section, we examine the aspects of Gener-
ics in C# presenting a real benefit for the devel-
oper.
3.1 Implementation of Generics
To really see the power of Generics in C# , we will
compare the implementation on a more detailed
and deeper level. But lets start with three differ-
ent definitions of a Parameterized Type Cup<T >
in C# (figure 1), Java (figure 2) and C++ (figure
3).
Even though the definitions and creations look
extremely similar to each other, the compiled re-
sult of the three examples are very different.
Compiled Generics in Java
The simplest integration (regarding the three
mentioned languages) of Parameterized Types
into the language and their execution environ-
ment, in this case the JVM, is done by Java. Java
uses a technique called Type Erasure ( [45], [44]).
Simply explained, this means throwing away the
3 THE GOOD

1 // D e f i n i t i o n 1 // D e f i n i t i o n
2 c l a s s Cup<T> 2 template<typename T>
3 { 3 c l a s s Cup {
4 T content ; 4 T content ;
5 } 5 }
6 6
7 // A p p l i c a t i o n 7 // A p p l i c a t i o n
8 var cupCake 8 Cup<Cake> cupCake ;
9 = new Cup<Cake > ( ) ; 9 Cup<C o f f e e > c u p C o f f e e ;
10 var c u p C o f f e e
11 = new Cup<C o f f e e > ( ) ; Figure 3: C++: Cup<T >

Figure 1: C#: Cup<T >

1 // D e f i n i t i o n
2 public c l a s s Cup {
1 // D e f i n i t i o n 3 private j a v a . l a n g . Object c o n t e n t ;
2 c l a s s Cup<T> { 4 }
3 T content ; 5
4 } 6 // A p p l i c a t i o n
5 7 new Cup
6 // A p p l i c a t i o n 8 i n v o k e s p e c i a l Cup ( )
7 Cup<Cake> cupCake 9 a s t o r e 1 [ cupCake ]
8 = new Cup<Cake > ( ) ; 10 new Cup
9 Cup<C o f f e e > c u p C o f f e e 11 i n v o k e s p e c i a l Cup ( )
10 = new Cup<C o f f e e > ( ) ; 12 astore 2 [ cupCoffee ]

Figure 2: Java: Cup<T > Figure 4: Resulting Java Bytecode of Cup<T >.

Type Parameters during compilation. The Type

Parameters are only used during compilation to
ensure the code is type-safe.
If we take the example of figure 2, the com-
piled code will look like figure 4. We notice that
Cup is no longer a Generic Type (line 2) and the
occurrence of Type Parameter T was replaced by
type Object (line 3).
Compiled Templates in C++
C++, compared to Java, applies the opposite ap-
proach. Rather than throwing away information,
the templates are separately compiled for every
combination of Type Parameters. Taking the ex-
ample from figure 3, the compiled code will look
like figure 5. As we can see, now there exist two
classes of Cup<T >, Cup<Cof f ee> (line 2) and
Cup<Cake> (line 2).
Compiled Generics in C#
Having seen the most extreme approaches of han-
dling Parameterized Types, we now turn to C#.
If code in C# is compiled, it gets compiled into
the so called Intermediate Language (further re-
ferred to as IL). This is a language used by the
CLR (Common Language Runtime) [9], a virtual
machine.
Despite the other two examples, where the
Type Parameters information gets either thrown
away or directly compiled into the type, the IL
actually supports Parameterized Types directly
[39]. This is possible since the CLR is able to
handle Parameterized Types ( [1], [2]).
If we compile the code in figure 1, the IL-code
will look like figure 6. We immediately notice
that there is only one definition of Cup0 1<T >
with a Type Parameter (line 2) and the field us-
ing it (line 4).
This integration of Generics into the virtual
machine provides certain advantages. Compared
to Java, it is possible to use Value Types [23] as

4
 3.2 Type Constraints

1 // D e f i n i t i o n 1 // D e f i n i t i o n
2 . c l a s s Cup<C o f f e e > { } 2 . c l a s s public Cup1<T>
3 . c l a s s Cup<Cake> { } 3 {
4 4 . f i e l d private ! T content
5 // A p p l i c a t i o n 5 }
6 . locals 6
7 ( [ 1 ] v a l u e t y p e Cup<Cake> 7 // A p p l i c a t i o n
8 cupCake , 8 . locals init
9 [ 2 ] v a l u e t y p e Cup<C o f f e e > 9 ( [ 0 ] c l a s s Cup1< c l a s s Cake>
10 cupCoffee ) 10 cupCake ,
11 [ 1 ] c l a s s Cup1< c l a s s C o f f e e >
Figure 5: Disassembled template Cup<T > in 12 cupCoffee )
C++. To easily compare the results, we compiled 13 newobj
our C++ -code to IL-code. 14 c l a s s Cup1< c l a s s Cake > : : . c t o r ( )
15 stloc .0
16 newobj
Generics without boxing [8] resulting in better 17 c l a s s Cup1< c l a s s C o f f e e > : : . c t o r ( )
performance and memory usage. Compared to 18 stloc .1
C++, the explosion of code compiled into a library
is limited to the necessary parts. The CLR will Figure 6: Disassembled class Cup<T > in IL-
expand and store a copy of a Generic Type when code.
it is needed during runtime. As a result, we can
compare Generic Types and they will only match
if the Type Parameters match as well (lines 2 to C# allows five different constraints:
7, figure 7).
class | struct
Thus the behavior of Generic Types in C# is
pretty similar to C++s templates but without the inheritance of class (or struct)
compilation overhead. But it is still possible to
access the raw Generic Type (line 10, figure 7). implementation of interface(s)
Another consequence, of the CLR still knowing
the Type Parameters, is the possible usage of the is subtype of other Type Parameter
Type Parameters in static context. For exam- existence of parameterless constructor
ple, a static field using a Type Parameter is com-
pletely valid (figure 8). It should be obvious that It is possible to leave mentioned restrictions, but
this is not possible in Java. Since static fields are if restrictions on Type Parameters are defined,
shared between different instances and Javas us- the order (as it is defined above) of restrictions
age of Type Erasure, it cant be guaranteed that has to be taken into account.
the Type Parameter T will be the same in every
instance. 3.2.1 class & struct
But static fields in Generic Types (at least in
C#) introduce some pitfalls a developer has to be The first possible restriction on a Type Param-
aware of. We will discuss them in section 5.1. eter is its basic structure. We can distinguish
between class and struct. class is in this case
maybe a bit misleading as it simply forces the
3.2 Type Constraints Type Parameter to be a Reference Type [22] and
this also includes interfaces.
Type Constraints are used to restrict Type Pa-
rameters respectively guarantee the implemen- Using class means:
tation of interfaces, inheritance of a class (or Type Parameter is nullable: Since the
struct) or some more C#-specific capabilities [10]. Type Parameter is a Reference Type, any field

5
3 THE GOOD

1 // t r u e 1 public T Convert<T, V>(V v a l u e )

2 typeof (Cup<Cake>) 2 where T : c l a s s
3 == typeof (Cup<Cake >); 3 where V : c l a s s
4 4 {
5 // f a l s e 5 // v a l i d
6 typeof (Cup<Cake>) 6 bool i s N u l l = v a l u e == null ;
7 == typeof (Cup<C o f f e e >); 7
8 8 // P o s s i b l e
9 // t r u e 9 // N u l l R e f e r e n c e E x c e p t i o n
10 typeof (Cup<Cake>) 10 bool eq =
11 . GetGenericTypeDefinition () 11 v a l u e . Equals ( otherValue ) ;
12 == typeof (Cup<C o f f e e >) 12
13 . GetGenericTypeDefinition ( ) ; 13 return v a l u e as T ; // v a l i d
14 }
Figure 7: Comparing Genetic Types in C#.
Figure 9: Example of class constraint.
1 // D e f i n i t i o n
2 c l a s s Cup<T> null unnecessary respectively not possible since
3 { the == operator is not guaranteed to be
4 static T content ; defined. As a consequence, we always have
5 } to compare values with the Equals() method
6 since this is always possible (figure 10). We will
7 // A p p l i c a t i o n provide a workaround for the missing operators
8 Cup<Cake >. c o n t e n t = new Cake ( ) ; in section 5.2.
9 Cake cake = Cup<Cake >. c o n t e n t ;
1 public T Convert<T, V>(V v a l u e )
Figure 8: A Type Parameter used in a 2 where T : struct
static field. 3 where V : struct
4 {
5 // i n v a l i d , == not d e f i n e d
or argument of the given Type Parameter might 6 bool i s N u l l = v a l u e == null ;
be null . On the other hand, comparing against 7
null is possible respectively must be considered 8 // v a l i d , v a l u e cannot be n u l l
(figure 9). 9 bool eq =
Casts with as are allowed : As a logi- 10 v a l u e . Equals ( o t h e r V a l u e ) ;
cal consequence of forcing the Type Parame- 11
ter to be a Reference Type, we can use it as 12 // T cannot be n u l l
type casting with as [7]. as is a safe cast in 13 // hence c a s t w i t h as i s i n v a l i d
C# returning either an instance of the targeted 14 return v a l u e as T ;
type or null (figure 9). 15 }
On the other side, we can restrict the Type Pa-
rameter to be a struct. In this case, only Value Figure 10: Example of struct constraint.
Types [23] are allowed.
Using struct means: As good as these restrictions to class and
Type Parameter must be non-nullable: struct may sound, in C# it is possible to declare
Since only Value Types are allowed we know any nullable Value Types and they dont fit any of
field or argument of the given Type Parameter both restrictions. We will discuss this issue in
cannot be null. This makes any check against section 4.3.2 in more detail.

6

default(T)
Another consequence of the distinction between
class and struct is that we cant determine the
default value of a given Type Parameter. If we
restrict to class, it is null . This is the same as
in Java. But if there is struct or no constraint
at all, its no longer possible to just assume that
null works as a default value. In this case, we
can use the default keyword. Applied with the
Type Parameter the default value of the given
Type Parameter is always returned.
Another possible approach would be using the
new() restriction described in section 3.2.3. But
this seems to be more of an ugly workaround to
get a valid value.
3.2.2 Inheritance & Interfaces
Lets consider a M achine<T > as shown in fig-
ure 11. Such a M achine<T > could fill every-
thing into a container (e.g. Cup<T >) as long
it implements IF illable<T >. As interesting as
1 c l a s s Machine<T>
2 {
3 void F i l l ( I F i l l a b l e <T> cup )
4 { ...
5 }
6 }
Figure 11: M achine<T >
a M achine<Cake> might sound we only want
a machine that can fill a Cup<T > with some-
thing to drink. To achieve this goal, we can
add a Type Bound on T to implement the in-
terface IBeverage. Thus line 1 in figure 11 will
be extended to allow only something implement-
ing IBeverage (figure 12) and our Cake-Machine
is history.
Besides interfaces, we could also force inher-
itance of a certain class or even another Type
Parameter (e.g. T : U ).
3.2.3 new()
As mentioned in the previous section, Type Pa-
rameter information still exists in the IL-code.
Due to this, it is possible to create a new instance
7
3.2 Type Constraints
1 c l a s s Machine<T>
2 where T : I B e v e r a g e
Figure 12: Constraining M achine<T > to allow
only beverages.
based on the Type Parameter. To do so, we can
extend the Type Parameters constraint with the
keyword new() requiring the Type Parameter to
provide a public parameterless constructor. If we
add this restriction to our M achine<T >, we can
now create new instances of our given Type Pa-
rameter (line 6, figure 13).
1 c l a s s Machine<T>
2 where T : IBeverage , new( )
3 {
4 void F i l l ( I F i l l a b l e <T> cup )
5 {
6 var b e v e r a g e = new T ( ) ;
7 cup . F i l l W i t h ( b e v e r a g e ) ;
8 }
9 }
Figure 13: A M achine<T > that can create
whatever beverage it is used for.
Such a capability with Type Parameters is cur-
rently not possible in Java since, as we mentioned
in section 3.1, the Type Parameters information
is gone after the code is compiled. There exists a
possibility to create instances of given Type Pa-
rameters using Class<T > but this is not in the
scope of this paper.
C++, on the other side, provides the same pos-
sibility. Since the compiler basically replaces T
with the type given by the Type Parameter, it
just has to provide an empty constructor that
is accessible within the template and its fine.
C++ goes even further. As it is just checked if
the expected signature exists, it is also possible
to force constructors with parameters. We will
discuss this missing feature in C# later in section
4.2.
3 THE GOOD
3.3 Co- & Contravariance
With the introduction of Generics some new
problems and pitfalls were also introduced. One
special case is the behavior involving subtyping.
More details on the topic of subtyping can be
found in another seminar paper by Gasser [34].
We will now have a look on the behavior when
Type Parameters are used in covariant and con-
travariant positions. Restrictions regarding vari-
ance will be discussed in section 4.4. In the fol-
lowing subsections we will only show how it is
used.
3.3.1 Covariance
Using Type Parameters in covariant positions
means using them only as return types. To define
a Type Parameter that is only used in covariant
positions, we can introduce the out keyword in
the interface declaration as shown in figure 14.
1 i n t e r f a c e IEmptyable<out T>
2 {
3 T Empty ( ) ;
4 }
Figure 14: Covariant IEmptyable<T > inter-
face. out denotes T will only be used in covariant
positions, meaning only as return type.
Now, if we assume we have a class Cup<T >
(figure 15) defined, we can assign instances of
Cup<T > to more generic interfaces of type
IEmptyable<T > as shown in figure 16.
1 c l a s s Cup<T>
2 : IEmptyable<T>
Figure 15: A Cup<T > implementing interface
IEmptyable<T >.
Regarding covariance, the above defined usage
also applies to Properties. If we define a Type
Parameter only used in covariant positions, it is
only applicable on getters as shown in figure 17.
8
1 IEmptyable<Cake> cupCake
2 = new Cup<Cake > ( ) ;
3 IEmptyable<IFood> f o o d
4 = new Cup<Cake > ( ) ;
5 IEmptyable<Tea> teaCup
6 = new Cup<IceTea > ( ) ;
Figure 16: Application of covariant
IEmptyable<T > interface.
1 i n t e r f a c e I C o n t a i n e r <out T>
2 {
3 T Content { g e t ; }
4 }
Figure 17: Covariant Property
3.3.2 Contravariance
Type Parameters in contravariant positions are
types of input parameters. To define that we will
only use Type Parameters on input parameters,
we can use the in keyword as shown in figure 18.
1 i n t e r f a c e I F i l l a b l e <in T>
2 {
3 void F i l l W i t h (T c o n t e n t ) ;
4 }
Figure 18: Contravariant IF illable<T > inter-
face. in denotes T will only be used in contravari-
ant positions, meaning only as input parameter
type.
If we again assume we have a class Cup<T >
(figure 19) implementing IF illable<T >, we can
now fill it with any matching subtype as shown
in figure 20.
Again, using Type Parameters in Properties, in
this case in a contravariant manner, is possible,
as long as we only define setters. Figure 21 shows
how it is done.

1 c l a s s Cup<T>
2 : I F i l l a b l e <T>
Figure 19: A Cup<T > implementing interface
IF illable<T >.
1 I F i l l a b l e <Tea> teaCup
2 = new Cup<Tea > ( ) ;
3 teaCup . F i l l W i t h (new Tea ( ) ) ;
4 I F i l l a b l e <IceTea> iceTeaCup
5 = new Cup<Tea > ( ) ;
6 iceTeaCup . F i l l W i t h (new IceTea ( ) ) ;
Figure 20: Application of contravariant
IF illable<T > interface.
4 The Bad
In this section we discuss the limitations of C#s
implementation of Generics.
4.1 Generic Properties
We mentioned in a previous section that Generics
can also be used with Properties. And we have
seen how Generics are used on methods. Since
Properties are just syntactic sugar for getter and
setter methods the question might come up if it
is possible to use Type Parameters in Property
definitions as shown in figure 22.
But Generic Properties are not possible. The
reason lies in the CLR. The compiler cannot
know how much space to allocate for storing an
instance (in our case a Container ) when it is cre-
ated, since T is only known when the Property is
accessed [15].
Now, there may be the followup question: Why
is this still prohibited when the Type Parameter
is not used as type of the backing field? Thus, we
limit the used scope of the Type Parameter to the
Propertys body and the compiler doesnt have
to worry when allocating space on the heap. The
question is legit since we said before that Proper-
ties are just another way of providing getter and
setter methods.
Lets try to find the difference in the IL-code.
If we take a class as shown in figure 23 the IL-
code would look like figure 24. When compiling,
9
4.2 Type Constraints
1 i n t e r f a c e I C o n t a i n e r <in T>
2 {
3 T Content { s e t ; }
4 }
Figure 21: Contravariant Property
1 class Container
2 {
3 T Content<T> { g e t ; s e t ; }
4 }
Figure 22: Property with Type Parameter.
we notice that the compiler already raises errors
since get Value() and set Value() are already re-
served by the class (the error occurs on line 3,
figure 23). For the sake of simplicity, we assume
the class is compilable as it is and the resulting
IL-code would be in the same class as well.
1 class Container
2 {
3 int Value { g e t ; s e t ; }
4 int get Value ( ) { . . . }
5 void set Value ( int v a l u e ) { . . . }
6 }
Figure 23: Class used to compare Properties
and methods.
As we see in figure 24, the differences are min-
imal. Getter and setter methods of Properties
only add a specialname token (compare lines 5
and 10 respectively lines 16 and 21). The re-
maining code is equal.
Hence, Generic Properties are basically not
possible because the compiler doesnt support
them.
4.2 Type Constraints
Regarding Type Constraints, even if they are
much more flexible than the capabilities provided
in Java, there exist some limitations.
4 THE BAD

1 . c l a s s public C o n t a i n e r For the other not supported classes, there is

2 { no hard evidence why they are not allowed. Re-
3 // P r o p e r t y g e t t e r garding System.Enum, there is exists a statement
4 . method private from Lippert (member of the C# language design
5 specialname int32 team).
6 get Value ( ) { . . . } ALL features are unimplemented until some-
7
one designs, specs, implements, tests, documents
8 // Method get Value and ships the feature. So far, no one has done
9 . method private that for this one. Theres no particularly unusual
10 int32 reason why not; we have lots of other things to
11 get Value ( ) { . . . } do, limited budgets, and this one has never made
12
it past the wouldnt this be nice? discussion in
13
the language design team. [13]
14 // P r o p e r t y s e t t e r We assume this statement is also valid for the
15 . method private other types in the list.
16 s p e c i a l n a m e void
17 set Value ( i n t 3 2 v alue ) { . . . } 4.3.1 Enums
18
19 // Method s e t V a l u e Even though we can constrain Type Parameters
20 . method private to be a class or struct (see section 3.2.1), it is
21 void not possible to force a Type Parameter to be an
22 set Value ( i n t 3 2 v alue ) { . . . } enum. According to [11], forcing an enum is
23 } possible if directly written in IL. But, as men-
tioned before, its simply not supported by the
compiler as it isnt that important for the devel-
Figure 24: IL-code of compiled Container to opment team.
compare Properties and methods. Unnecessary The closest possible constraint in C# for
details are omitted. enum types is to use struct since enums are
Value Types [2].
4.3 Unusable superclasses
4.3.2 Nullable Types
If we want to constraint our Type Parameter to
inherit from a specific superclass we cannot use Using the keyword struct as Type Constraint
the following five classes: for Value Types is a bit misleading since not all
structs are allowed. C# knows a construct called
System.Array N ullable<T > (short T ?) [16] allowing to wrap
Value Types and assign null. If we have a look
System.Delegate

System.Enum 1 // i n v a l i d
2 int i = null ;
System.ValueType 3
4 // v a l i d
object 5 N u l l a b l e <int> j = null ;
6 int ? k = null ;
While these types exist in the framework, it is not
possible to use them for inheritance since they
are attached implicitly. Furthermore, constrain- Figure 25: Assigning null to Nullable Types.
ing to object is useless since every Type Param-
eter T fulfills this constraint as long as no other at the implementation we see that N ullable<T >
constraint is more specific. is in fact implemented as a struct making it a

10
 4.3 Unusable superclasses

Value Type. But on the other hand, null is a 1 // v a l i d

valid value. 2 Use (new object ( ) ) ;
Regarding Type Constraints for Type Param- 3
eters, this is pretty confusing and in fact as soon 4 // i n v a l i d
as a Type Constraint of either class or struct is 5 // i m p l e m e n t a t i o n on l i n e 1
present, it is not possible to use a Nullable 6 // o f f i g u r e 26 i s used
Type. Since class expects a Reference Type, 7 Use<int > ( 4 2 ) ;
what N ullable<T > is not, and struct expects a 8
non-nullable Value Type, what is N ullable<T > 9 // v a l i d
either, non of these constraints are applicable. 10 Use ( ( int ? ) 4 2 ) ;
The only possible option, when Nullable Types 11
have to be allowed, with one of the two con- 12 // v a l i d
straints is providing two separate implementa- 13 int ? theAnswer = 4 2 ;
tions applying the restrictions separated from 14 Use ( theAnswer ) ;
each other. If this scenario occurs on a method
its not that hard to solve. Since T ? changes the
Figure 27: Usage of overloaded methods with
Nullable Types.
1 void Use<T>(T item )
2 where T : c l a s s { . . . }
3
1 T Create<T>()
4 void Use<T>(T? item ) 2 where T : new( )
5 where T : struct { . . . } 3 {
4 return new T ( ) ;
5 }
Figure 26: Overload with Nullable Type.

Figure 28: Example of using new() constraint.

method signature by the input type the compiler
can distinguish them (figure 26). But the us-
age will look a bit ugly since we have to force the
cast of any Value Type to get the correct method
as shown in figure 27. The problem here lies in
the fact that the implementation on line 1 in fig-
ure 26 matches the method application the most.
In fact, any time an overloaded method with a
N ullable<T > should be called the nullable ar-
gument has to be either casted to the expected
Nullable Type (line 10, figure 27) or has to be
already stored in a variable of the expected Nul-
lable Type (line 13, figure 27).
More on the subject of N ullable<T > can be
found at [19].
this is not possible (figure 29).
1 T Create<T>( int v a l u e )
2 where T : new( int ) // i n v a l i d
3 {
4 // i n v a l i d
5 return new T( v a l u e ) ;
6 }
Figure 29: Impossible usage of generic param-
eterized constructor.

4.3.3 new() Optional parameters

The introduction of new has its bene-
fits. For example we can write a generic
F actoryM ethod<T >() [32] that looks like figure
28. As simple this may look, thats all new can
offer. But sometimes we may be interested in
calling a constructor with input parameters and
new takes it very seriously with the parameter-
less constructor. If the new restriction is set on
a Type Parameter, it isnt even possible to use a
constructor with an optional parameter. Assum-
ing we can create a class Coffee that may contain
some sugar. Since some like it without any sugar
we leave this parameter optional.

11
4 THE BAD

Our M achine<T > expects a type that has a 1 i n t e r f a c e IEmptyable<out T> { }

parameterless constructor. But trying to create a 2 c l a s s Cup<T> : IEmptyable<T> { }
M achine<Cof f ee> is not possible even it seems 3
that Coffee has a parameterless constructor (line 4 IEmptyable<IBeverage > cup
12, figure 30). 5 = new Cup<C o f f e e > ( ) ;

1 class Coffee Figure 31: Covariant assignment in C#. Notice

2 { that the covariant usage of T is defined on the
3 C o f f e e ( double s u g a r = 0 . 0 ) interface where it is actually used.
4 { ...
5 }
6 } 1 i n t e r f a c e Emptyable<T> { }
7 2 c l a s s Cup<T>
8 c l a s s Machine<T> 3 implements Emptyable<T> { }
9 where T : new( ) { . . . } 4

10 5 Emptyable<? extends Beverage> cup

11 // v a l i d 6 = new Cup<C o f f e e > ( ) ;
12 var c o f f e e = new C o f f e e ( ) ;
13 Figure 32: Covariant assignment in Java. No-
14 // i n v a l i d tice that the covariant usage of T is defined when
15 var c o f f e e M a c h i n e it is used.
16 = new Machine<C o f f e e > ( ) ;

Figure 30: new() and its limitations.
4.4 Co- & Contravariance
If we compare the definition and application of
Generics regarding co- & contravariance between
C# and Java we see two major differences. One
difference affects the point in time when we define
the variance (section 4.4.1) and the other is a re-
striction on what concepts we can define variance
on (section 4.4.2).
4.4.1 Variance when defined
As seen in section 3.3 in C#, the usage of Type
Parameters is defined on the interface using them
(figure 31). In Java we use the opposite approach
(figure 32). Here we define the usage when the
concrete type is set.
Assuming we assign a Cup<Cof f ee> to an in-
terface IEmptyable<IBeverage>. According to
the domain model in appendix A this assignment
works since IEmptyable<T > is using T only in
a covariant position.
Comparing the examples in figure 31 and 32,
we see the two different approaches, when to us-
ing a Type Parameter in a covariant position.
The solution Java offers looks more flexible since
we dont have to restrict the Type Parameter
while defining the interface. But this raises the
following two concerns:
Too much to think about
In Java we have to use the wildcard ? on every
occasion we want to use the interface in a covari-
ant (or contravariant) manner. This means, we
have to give a thought on variance every time
we use the interface. And this is probably a lot.
Obviously, equally or more times we defined the
interface.
On the other side, we have the restrictive ap-
proach of C# where the interface forces us to use
T only on covariant (or contravariant) positions.
The upside, we have to think on variance once,
when we define the interface, and when using it,
we just have to guarantee the relation between
the types (in our case Cof f ee and IBeverage)
is correct. And just thinking about their rela-
tionship is much more easier than dealing with
the covariance itself.

12
Crippling the interface
Another concern may be the inflexible usage of
an interface in co- or contravariant way. As men-
tioned before, in C# we have to decide in what
positions a Type Parameter will be used within
an interface when we define the interface. When
the Type Parameter is used at an invalid position
(eg. covariant Type Parameter at an contravari-
ant position) the compiler will raise an error.
Thus we are forced to only use Type Parameters
at positions we allow them when we define the in-
terface. As a result interfaces will be either com-
pletely covariant (only used for access) or con-
travariant (only used for modifications). Hence,
interfaces contribute their share to get high co-
hesion [42] which is definitely not bad.
If we now have a look into Java, where such a
restriction doesnt exist. The definition of an in-
terface doesnt care where the Type Parameters
are used. If the interface is used in a covariant
manner, the compiler will raise an error if we try
to call a method that uses the Generic Type in a
contravariant manner. As a result, as soon as we
define to use only the interfaces covariant meth-
ods, we cripple the interface by prohibiting all
methods that use the Type Parameter at con-
travariant positions as shown in figure 33. We
1 L i s t <? extends Tea> d r i n k s
2 = new A r r a y L i s t <IceTea > ( ) ;
3 since it may sound a bit restrictive to develop-
4 // i n v a l i d
5 d r i n k s . add (new IceTea ( ) ) ;
Figure 33: Covariant List<T > in Java.
could now argue that in Java it is possible to
follow the same design as in C# with separated
interfaces for covariant and contravariant meth-
ods. This is true but we are still not forced to do
so by the language.
4.4.2 Variance only on interfaces
In C#, we can only use the in and out keywords
on interfaces. Using them in a Generic Class defi-
nition is not possible. One reason this restriction
exists in C# is based on the fact that the CLR
does only support variance on interfaces but not
13
classes [29].
Another reason, and slightly more meaningful,
is its necessity. As long as we can work with
classes in a co- or contravariant way through in-
terfaces, we are not really restricted. At least
we can accomplish the same as if we would have
variance on classes.
The problem with variance on classes lies in its
usability. As soon as we want to use a Type Pa-
rameter in a field we need it to be invariant since
a field can be accessed and written to. The only
exception here would be a readonly [21] field
exposing its content in a covariant manner [29].
Thus, the only applicable scenario for a covariant
class would be if it represented something im-
mutable ( [25], [24]) or at maximum would only
allow reductions on its internal values bound to
the Type Parameter. On possible class could be
a list only allowing accessing its items, removing
or clearing them but not adding any new items.
The benefits of having variance on classes com-
pared to the costs implementing it in the CLR
are just not reasonable. Despite the costs, we
currently can do everything through interfaces.
Hence we couldnt even solve any problems in an
easier way. Furthermore, forcing the usage of in-
terfaces doesnt force us to use a specific class
thus we could easily exchange the class imple-
menting the interface.
We listed these two differences as limitations
ers. Even though, we think this restrictive ap-
proaches lead to much cleaner code. And are not
really preventing us from doing less as if these
limitations were not present.
5 The Ugly
So far, we presented the capabilities of Generics
in C# (section 3) and where we encounter limita-
tions (section 4). In this section, we discuss top-
ics where using Generics is possible but running
into a pitfall is likely to happen, or the resulting
solution just wont look that nice.
5.1 Generics and static
As mentioned in section 3.1, Generic classes will
be expanded and stored separately for every
5 THE UGLY
Type Parameters when used for the first time.
Since these expanded Generic classes behave like
different types, static fields can contain unex-
pected values or references.
Assuming we want to track the number of cups
we have created. To accomplish that, we extend
the definition of Cup<T > with a counter and a
property to access its value (figure 34).
1 c l a s s Cup<T>
2 {
3 s t a t i c int counter ;
4 Cup ( ) { counter++; }
5 int Counter
6 {
7 g e t { return counter ; }
8 }
9 }
Figure 34: Counting Cup<T > constructor
calls.
If we now create some cups, the counter will
contain the values shown in figure 35.
1 var cup1 = new Cup<Cake > ( ) ;
2 // cup1 . Counter == 1
3 var cup2 = new Cup<Cake > ( ) ;
4 // cup2 . Counter == 2
5 var cup3 = new Cup<C o f f e e > ( ) ;
6 4
7 // cup3.Counter == 1!
Figure 35: Counting cups
If we are aware of the CLRs handling of
Generic Types, this example sounds completely
reasonable. But if one lacks such background
knowledge, it may result in unexpected behav-
ior since static fields seem not to work as they
usually do (line 7, figure 35).
Another pitfall in this scenario is waiting for
the developer who is Refactoring. As mentioned
by Fowler [31] Refactoring is the process of
changing a software system in such a way that it
does not alter the external behavior of the code
yet improves its internal structure. In the same
book, he mentions a Refactoring called Extract
14
Superclass which moves some parts of an exist-
ing class into a superclass.
If we now apply this Refactoring to our
Cup<T > class, the resulting code will look like
figure 36. The code seems to look the same. We
1 c l a s s BaseCup
2 {
3 s t a t i c int counter ;
4 BaseCup ( ) { counter++; }
5 int Counter
6 {
7 g e t { return counter ; }
8 }
9 }
10
11 c l a s s Cup<T>
12 : BaseCup { }
Figure 36: Applying Extract Superclass on
Cup<T >.
just moved the content of Cup<T > into a super-
class and introduced inheritance.
If we now count our cups, we get some inter-
esting results (line 7, figure 37). Even though we
1 var cup1 = new Cup<Cake > ( ) ;
2 // cup1 . Counter == 1
3 var cup2 = new Cup<Cake > ( ) ;
// cup2 . Counter == 2
5 var cup3 = new Cup<C o f f e e > ( ) ;
6
7 // cup3.Counter == 3!
Figure 37: Refactored cup counting
only refactored the code, we altered its behavior,
too.
We leave it up to the reader deciding if it is
still a Refactoring or not. In our opinion it still
is. The destruction of existing behavior is simply
based on the implementation of Generics in the
CLR and the fact, that we moved something from
a Generic into a non-Generic class.
But it gets worse. The same behavior is repro-
ducible if we inherit from a Generic Type. As-
suming we have a Cup<T, E> inheriting from

our Cup<T > (figure 34). The implementation
of Cup<T, E> looks like 38 where we see that
the Type Parameter T is passed to the super-
class (line 2). If we now create some instances
1 c l a s s Cup<T, E>
2 : Cup<T> { }
Figure 38: Definition of Cup<T, E>.
of Cup<T, E> (figure 39) we notice that the
counter (line 10) in the superclass gets incre-
mented on every constructor call that has the
same Parameter Type (in our case Coffee).
1 var cup1 =
2 new Cup<C o f f e e , Milk > ( ) ;
3 var cup2 =
4 new Cup<C o f f e e , WhippedCream > ( ) ;
5 var cup3 =
6 new Cup<Cake , WhippedCream > ( ) ;
7 4
8 var cup4 = new Cup<C o f f e e > ( ) ;
9 6
10 // cup4.Counter == 3!
Figure 39: Counting Cup<T, E>
To sum up, using static in Generic Types is
dangerous. Especially, when we introduce inher-
itance. And we have to be aware of potential side
effects when Refactoring Generic Types contain-
ing static values (e.g. fields).
5.2 Operator overloading
In section 2, we mentioned the difference between
implicitly and explicitly Generic Programming.
Since C# forces us to define explicitly the capabil-
ities of Type Parameters with Type Constraints,
we are bound to the possibilities the language
offers. These Type Constraints cover a broad
area of restrictions we can force the Type Pa-
rameters have to fit in. But there is one concept
we cant enforce by the given Type Constraints.
And these are operators.
As in C++, it is possible to overload operators
in C#. But we are slightly limited in the pos-
sibilities where to overload them. In C++, we
15
5.2 Operator overloading
can either overload them as a class member or
in several cases outside classes [20]. In C#, we
encounter two major differences [14]:
1. An operator can only be overloaded within
a class one of the input parameters belongs
to
2. An overloaded operator has to be static
While the first difference is obvious (despite del-
egate definitions nothing can be defined outside
a class) the latter introduces some hard restric-
tions.
But lets first have a look how we could provide
a simple implementation to sum some amount
of Tea. Figure 40 shows how an + operator
could be implemented for Tea and in figure 41
we mention its usage.
1 c l a s s Tea
2 {
3 double amount ;
Tea ( double a ) { amount = a ; }
5 s t a t i c Tea operator+
( Tea l h s , Tea r h s )
7 {
8 return new Tea
9 ( l h s . amount + r h s . amount ) ;
10 }
11 }
Figure 40: Tea with + operator .
1 var f i r s t D r i n k = new Tea ( 5 ) ;
2 var secon dDrink = new Tea ( 3 ) ;
3
4 var iDrank = f i r s t D r i n k
5 + sec ondDrink ;
Figure 41: Drinking Tea
Now we know how operators can be overloaded
for types. Lets have a look how this may work
in context of Generic Types.
First of all, the forced usage of the
static keyword when overloading operators
reduces our options to introduce opera-
tor overloads on Type Parameters. Since
5 THE UGLY

interfaces dont allow any static declarations 1 c l a s s Pot<T> : I F i l l a b l e <T>

and the other Type Constraints wont help ei- 2 where T : BevOps<T>, I B e v e r a g e
ther, only a superclass Type Bound can be used 3 {
(section 5.2.1). Or we could simply abandon the 4 T liquid ;
Type System (section 5.2.2). 5 void F i l l W i t h (T l i q u i d )
6 {
5.2.1 Operator inheritance 7 liquid = liquid + liquid ;
8 }
Lets have a look on the approach with a su-
9 }
perclass. The provided solution is a slightly ex-
tended version found at [18].
In C#, operator overloads can be inherited. Figure 43: P ot<T >
This means when we overload operators any sub-
class is aware of, and could work with them.
If we want to accumulate the amount of liquid use operators within Generic Types, we want to
in a P ot<T >, we have to introduce a superclass discuss some ugly aspects.
providing the + operator. Therefore we create First of all, we need a strong dependency
a class BevOps<T > (figure 42) we can inherit (inheritance) between our Type Parameter and
from. In figure 43, we show a P ot<T > we can BevOps<T > to setup the Type Constraint (line
2, figure 43). But introducing a new superclass
1 abstract c l a s s BevOps<T> into an existing type hierarchy is not always pos-
2 { sible.
3 protected abstract T Add(T r h s ) ; Second, since BevOps<T > is invariant (sec-
4 tion 4.4.2), as soon as we inherit from Tea, we
5 s t a t i c T operator+ cant use P ot<T > anymore for the new subclass
6 ( BevOps<T> l h s , T r h s ) (figure 44). P ot<IceT ea> expects IceTea to be
7 { a subclass of BevOps<IceT ea> but it is one of
8 return l h s == null BevOps<T ea> since we inherited from Tea.
9 ? rhs
10 : l h s . Add( r h s ) ;
11 } 1 c l a s s IceTea : Tea { . . . }
12 } 2
13 3 // v a l i d
14 c l a s s Tea : BevOps<Tea> 4 var t ea Po t = new Pot<Tea > ( ) ;
15 { ... 5
16 override Tea Add ( Tea r h s ) 6 // i n v a l i d
17 { 7 var i ce T e aP o t = new Pot<IceTea > ( ) ;
18 return new Tea (
19 amount + r h s . amount ) ;
Figure 44: Subclass of Tea is not usable as Type
20 }
Parameter on P ot<T >.
21 }

Figure 42: Defining and unsing BevOps<T >.
accumulate the filled-in liquid using the + op-
erator. This is possible since the BevOps<T >
superclass is used as a Type Constraint on Type
Parameter T .
Even though we provided a solution how to
If we want to get rid of this strong depen-
dency, we could remove the Type Parameter of
BevOps<T >. But in this case, we would have
to make some assumptions on the type returned
by the + operator. In particular we could only
work with BevOps types and would have to cast
them into the correct types.

16
 5.2 Operator overloading

5.2.2 Using dynamic really a key benefit of C#s rich Generics imple-
mentation. But compared to the first possible
With the previously presented solution on work-
implementation, discussed in section 5.2.1, using
ing with operators by using a superclass, we tried
dynamic seems to be the simpler implementa-
to stick with the Type System. Another solu-
tion as long as we know what we are doing.
tion to enable the usage of operators on Type
Furthermore, using dynamic slightly reminds
Parameters would be by abandoning the Type
us of using a template in C++ (figure 47).
System. In C#, we can do this with the dy-
As mentioned at the beginning, templates in
namic keyword [12].
C++ implicitly force its Type Parameters to sup-
If dynamic is used, we basically bypass the
port whatever the templates implementation
Type System and expect everything will work at
needs. The main difference, between using dy-
runtime, or we will then get an exception. The
idea for this solution is based on the summary
found at [18] and the discussion on [6]. 1 c l a s s Tea
The implementation in this case would look 2 {
like figure 45. We assume T implements the + 3 private :
4 double amount ;
1 c l a s s Pot<T> : I F i l l a b l e <T> 5 public :
2 where T : I B e v e r a g e 6 Tea ( double amount )
3 { 7 : amount ( amount ) { . . . }
4 T liquid ; 8 Tea operator+(const Tea &r h s )
5 void F i l l W i t h (T l i q u i d ) 9 const {
6 { 10 return Tea ( amount
7 liquid = 11 + r h s . amount ) ;
8 ( dynamic ) l i q u i d + l i q u i d ; 12 }
9 } 13 }
14
10 }
15 template<typename T>
16 c l a s s Pot : public F i l l a b l e <T>
Figure 45: Using the + operator with dy- 17 {
namic. 18 private :
19 double liquid ;
operator that takes something of type T on both 20 public :
sides of the operator and will return a result of 21 void F i l l W i t h (T c o n t e n t )
type T . 22 override {
If we now use our first implementation of Tea 23 liquid = liquid + liquid ;
(figure 40), we can use Tea as a valid Type Pa- 24 }
rameter for P ot<T > (figures 45 & 46). As men- 25 }

1 var t ea Po t = new Pot<Tea > ( ) ;
2 t ea Po t . F i l l W i t h (new Tea ( 4 ) ) ;
3 t ea Po t . F i l l W i t h (new Tea ( 5 ) ) ;
Figure 46: Filling a P ot<T ea>.
tioned, we bypass the Type System but dont
have to introduce any new classes or dependen-
cies.
The downside of using dynamic is the loss of
compile-time Type Checking. This is otherwise
Figure 47: P ot<T ea> example in C++.
namic in C# (in the discussed situation) and the
C++ template, is the point in time you may notice
the + operator is missing.
As mentioned before, in C# the check, if the +
operator exists, is done at runtime. If missing,
we will get a Microsoft.CSharp.RuntimeBinder.
RuntimeBinderException with a message like
Cannot implicitly convert type string to Tea
but no hint that there is an operator missing.

17
6 CONCLUSION
Having a deeper look at the message we real-
ize that not even the missing + operator is the
root cause of the exception but the assignment
of the value back to the field. The missing +
operator simply results in a string contain-
ing the type of the field or parameter the dy-
namic keyword was used on.
But there exists the possibility to get an ex-
ception message we can really work with. We
can slightly modify our usage of the + opera-
tor by moving dynamic to the right-hand side
parameter (of an expected binary operator) as
shown in figure 48. Now we will get an exception
message like Operator + cannot be applied to
operands of type Tea and Tea which really
tells us what the problem is. Hence, we have
1 liquid =
2 l i q u i d + ( dynamic ) l i q u i d ;
Figure 48: dynamic on right-hand side param-
eter of + operator.
to keep in mind when using dynamic to enable
operator overloading we should cast the right-
hand side parameter. We could go even further
with using dynamic but this would be out of the
scope of this paper. If anyone is interested, there
is a whole section on dynamic in [26].
On the other side, C++ will say that the + op-
erator is missing at compile-time, right away.
The goal of this section was to present a solution
on how to use operators within Generic Types.
We know there is the possible solution of provid-
ing an interface with methods instead of using
operators. In this case we could have simply used
the interface as Type Constraint.
But using operators is possible with Generics.
Its just a question of how much we want to pay
for that.
5.3 Stacking Type Parameters
We introduced in section 3.2.2 a M achine<T >
for beverages. The downside of this
M achine<T > was that we had to provide
our own Cup<T > to fill the beverage in. How
18
about a vending machine that could provide the
cup with the beverage?
A possible V endingM achine<C, T > could
look like figure 49 and its application like figure
50.
1 c l a s s VendingMachine<C, T>
2 where C : I F i l l a b l e <T>, new( )
3 where T : IBeverage , new( )
4 {
5 C GetProduct ( ) { . . . }
6 }
Figure 49: V endingM achine<C, T >
1 var machine
2 = new VendingMachine
3 <Cup<C o f f e e >, C o f f e e > ( ) ;
4
5 var cup = machine . GetProduct ( ) ;
Figure 50: Application of
V endingM achine<C, T >.
We see right away that we have to specify
Coffee twice. We could get rid of this du-
plication, if we simply replace Cup<Cof f ee>
with Cup<IBeverage>. But this would only
be cosmetic. Omitting the Type Parameter of
Cup<T > is also not an option since the con-
straint (line 2, figure 49) wouldnt be fulfilled,
anymore.
What we actually want, is the ability to expect
a Type Parameter to be a Generic Type. Thus we
could shorten the Type Parameters by stacking
them. The definition and application then would
look like figure 51. But unfortunately that is not
supported.
6 Conclusion
We gave a broad summary on the capabilities of
Generics in C#. While the capabilities in the first
part are well known among C# developers, since
they are normally mentioned when learning the
language, not many are familiar with their limi-
tations. This is mainly due the fact that Generics
1 c l a s s VendingMachine<C<T>> ics where a simple interface may also had done
2 where . . . the trick. The line between using Generics and
3
over-engineering is thin and blur.
4 var machine But at the end, we cant imagine an object-
5 = new VendingMachine oriented world with type-safety but without
6 <Cup<C o f f e e > >(); Generics or some other implementation of Pa-
rameterized Types. They make coding easier, es-
pecially when working with containers (List, Set,
Figure 51: Definition and application of etc), as long as we know what we are doing.
V endingM achine<C<T >>.

in C# are a mighty concept. If limits are reached,

one is trying to find them (as we did writing this
paper), or Generics are not that well known by
the developer.
Despite Generics in Java, Generics in C# are
deeply integrated into the language, even into the
virtual machine. Furthermore, rich support con-
straining Type Parameter is offered. Used in the
correct way, Generics can be a real support pur-
suing the DRY-principle.
But Generics are no silver bullet. If Gener-
ics are used, there is some serious software engi-
neering effort expected from the developer. One
should know when and where to use Generics es-
pecially what it means for the types that will be
used as Type Parameters, or limitations will be
hit, soon.
Furthermore, Generics made the developer
deal with co- & contravariance when defining
Generic Types. In the era before Type Parame-
ters the types within a signature simply had to be
the same, when calling we could put in subtypes
and expect supertypes as a result. Generics re-
moved the forced signature equality for the price
that a developer now has to deal with it. Luckily
the designer of C# (an the CLR) did a great job
and dealing with co- & contravariance is not that
hard if one has understood the concept.
After one has mastered Generics, pitfalls might
not open often. But knowing, applying and
preaching Generics, one has always be aware of
their power. Even though the smell Speculative
Generality was mentioned in Fowlers book on
Refactoring [31] in 1999, when Generics in Java
only existed on drafts and forks of the language
and C# not even existed, Generics brought Spec-
ulative Generality to a whole new level. Many
(including the authors) have introduced Gener-

19
REFERENCES

References
[1] Ecma tr/89: Common language infrastructure (cli) - common generics. http://www.
ecma-international.org/publications/techreports/E-TR-089.htm, 6 2006.

[2] Ecma-335: Common language infrastructure (cli). http://www.ecma-international.org/

publications/standards/Ecma-335.htm, 6 2012.

[3] C++ . http://www.cplusplus.com/, 11 2014.

[4] C# language specification 5.0. http://www.microsoft.com/en-us/download/details.aspx?id=

7029, 11 2014.

[5] Java 8 language specification. https://docs.oracle.com/javase/specs/jls/se8/html/index.

html, 11 2014.

[6] Arithmetic operator overloading for a generic class in C# . http://stackoverflow.com/

questions/756954/arithmetic-operator-overloading-for-a-generic-class-in-c-sharp, 5
2015.

[7] as. https://msdn.microsoft.com/en-us/library/cscsdfbt.aspx, 5 2015.

[8] Boxing and unboxing. https://msdn.microsoft.com/en-us/library/yz2be5wk.aspx, 5 2015.

[9] Common language runtime (clr). https://msdn.microsoft.com/en-us/library/8bs2ecf4%28v=

vs.110%29.aspx, 5 2015.

[10] Constraints on type parameters. https://msdn.microsoft.com/en-us/library/d5x73970.aspx,

5 2015.

[11] Create generic method constraining t to an enum. http://stackoverflow.com/questions/79126/

create-generic-method-constraining-t-to-an-enum, 6 2015.

[12] dynamic. https://msdn.microsoft.com/en-us/library/dd264741.aspx, 5 2015.

[13] Enum type constraints in C# . http://stackoverflow.com/questions/1331739/

enum-type-constraints-in-c-sharp, 6 2015.

[14] General rules for operator overloading. https://msdn.microsoft.com/en-us/library/4x88tzx0.

aspx, 5 2015.

[15] Generic properties. http://www.boyet.com/Articles/GenericProperties.html, 5 2015.

[16] N ullable<T > structure. https://msdn.microsoft.com/en-us/library/b3h38hb0%28v=vs.110%

29.aspx, 5 2015.

[17] Generics for .net. http://research.microsoft.com/en-us/um/people/akenn/generics/index.

html, 5 2015.

[18] Making generics add up. http://www.developerfusion.com/article/84413/

making-generics-add-up/, 5 2015.

[19] Nullable types (C# programming guide). https://msdn.microsoft.com/en-us/library/

1t3y8s4s.aspx, 5 2015.

[20] operator overloading. http://en.cppreference.com/w/cpp/language/operators, 5 2015.

20
 REFERENCES

[21] readonly. https://msdn.microsoft.com/en-us/library/acdd6hb7.aspx, 6 2015.

[22] Reference types. https://msdn.microsoft.com/en-us/library/490f96s2.aspx, 5 2015.

[23] Value types. https://msdn.microsoft.com/en-us/library/s1ax56ch.aspx, 5 2015.

[24] Why does C# (4.0) not allow co- and contravariance in generic
class types? http://stackoverflow.com/questions/2541467/
why-does-c-sharp-4-0-not-allow-co-and-contravariance-in-generic-class-types, 5
2015.

[25] Why isnt there generic variance for classes in C# 4.0? http://stackoverflow.com/
questions/2733346/why-isnt-there-generic-variance-for-classes-in-c-sharp-4-0/
2734070#2734070, 5 2015.

[26] Joseph Albahari and Ben Albahari. C# 5.0 in a Nutshell: The Definitive Reference. OReilly
Media, Inc., 2012.

[27] James C Dehnert and Alexander Stepanov. Fundamentals of generic programming. In Generic
Programming, pages 111. Springer, 2000.

[28] Gabriel Dos Reis and Bjarne Stroustrup. Specifying C++ concepts. ACM SIGPLAN Notices,
41(1):295308, 2006.

[29] Burak Emir, Andrew Kennedy, Claudio Russo, and Dachuan Yu. Variance and generalized con-
straints for C# generics. In ECOOP 2006Object-Oriented Programming, pages 279303. Springer,
2006.

[30] Martin Fowler. Code smell. http://martinfowler.com/bliki/CodeSmell.html, 2 2006.

[31] Martin Fowler, Kent Beck, J Brant, William Opdyke, and Don Roberts. Refactoring: Improving
the design of existing programs. Addison-Wesley Reading, 1999.

[32] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns: elements of
reusable object-oriented software. Pearson Education, 1994.

[33] Ronald Garcia, Jaakko Jarvi, Andrew Lumsdaine, Jeremy G Siek, and Jeremiah Willcock. A
comparative study of language support for generic programming. In OOPSLA, volume 3, pages
115134, 2003.

[34] Andre Gasser. The concept of subtyping explained from a type systems perspective. In Seminar:
Types and Program Transformation, 2015.

[35] Daniel Giovannelli. Programming in algorithms: Generic programming and its implementation.
2013.

[36] Andy Hunt and Dave Thomas. The Pragmatic Programmer: From Journeyman to Master. Addison-
Wesley Professional, 1999.

[37] Andrew Kennedy. Variance and generalized constraints for C# generics. http://research.
microsoft.com/en-us/um/people/akenn/generics/ECOOP06.ppt, 7 2006.

[38] Andrew Kennedy and Claudio V Russo. Generalized algebraic data types and object-oriented
programming. In ACM SIGPLAN Notices, volume 40, pages 2140. ACM, 2005.

21
REFERENCES

[39] Andrew Kennedy and Don Syme. Design and implementation of generics for the. net common
language runtime. In ACM SigPlan Notices, volume 36, pages 112. ACM, 2001.

[40] Andrew Kennedy and Don Syme. Combining generics, pre-compilation and sharing between
software-based processes. contexts, 3(19):11, 2004.
[41] Andrew Kennedy and Don Syme. Pre-compilation for .net generics. Microsoft Research, Cambridge,
UK, 2005.
[42] Craig Larman. Applying UML and patterns: an introduction to object-oriented analysis and design
and iterative development. Pearson Education India, 2005.
[43] David R Musser and Alexander A Stepanov. Generic programming. In Symbolic and Algebraic
Computation, pages 1325. Springer, 1989.
[44] Jaime Nino. The cost of erasure in java generics type system. Journal of Computing Sciences in
Colleges, 22(5):211, 2007.
[45] Benjamin C Pierce. Types and programming languages. MIT press, 2002.
[46] Jon Skeet. C# in Depth. Manning, 2008.
[47] Andrew Sutton and Bjarne Stroustrup. Design of concept libraries for c++. In Software Language
Engineering, pages 97118. Springer, 2012.
[48] Dachuan Yu, Andrew Kennedy, and Don Syme. Formalization of generics for the. net common
language runtime. In ACM SIGPLAN Notices, volume 39, pages 3951. ACM, 2004.

22
A Domain model

Figure 52: Domain model of used examples.

The domain model in figure 52 uses a C#-ish notation of Parameterized Types and Type Parameter
Constraints (annotations see table 1) but should be easily understood.

in T Denotes a Type Parameter T will only be used in a contravariant position (input parameter)
out T Denotes a Type Parameter T will only be used in a covariant position (return type)
where T Denotes a Type Constraint on possibly usable types for the Type Parameter T

Table 1: Annotations on domain model.

23