Develop Reference

Why Template parameter is Interface but I am asked anyway to use "default(I)"?

I think it is a bit strange, I want "I" to be only a interface type, and T being a class implenenting that interface type (or extending it).
Seems either I'm unable to set "null" value or to force correctly to just restrict the template to interface type.
public class MyClass< T, I> where T: I
{
private I myInterface = null; // error here. I have to use "default(I)"
}
Am I forcing correctly to have I "interface" ? otherwise why should I have to use "default(I)"?
The reason to use I is because T has overloaded null check operator (I'm using Unity3D and hence I have to check equality over interface to avoid a bottleneck.
Well in reality I have:
public class MyClass< T, I>: MonoBehaviour, where T: MonoBehaviour, I
{
private I myInterface = null; // error here. I have to use "default(I)"
}

Because the code below is a valid implementation to your generic type parameters, you can't be 100% sure T is a class (the only type being nullable):
MyClass<int, IEquatable<int>> m;
However, using the class constraint, it is:
public class MyClass<T, I> where T: I where I : class
{
private I myInterface = null; // <-- now it is valid
}

Cannot convert type `ObjectPool<T>' to `ObjectPool<ObjectPoolObject>'

I have a simple ObjectPool implementation. The ObjectPool holds a stack of ObjectPoolObjects. ObjectPoolObject is an abstract class that defines two methods. I am trying to add a reference to the parent pool to the ObjectPoolObject class. I got to work by using the curiously recurring template pattern, but then i couldnt derive from a class that was already deriving from ObjectPoolObject. (ie, grenade inherits from bullet which inherits from ObjectPoolObject)...
So anyways, the parent pool is held by the ObjectPoolObject like so: ObjectPool m_parent... but I cant seem to set m_parent = this; in the ObjectPool class... It seems like I definetly should be able to. I dont want to have to cast to object and then cast to ObjectPool.. it seems like I should safely be able to do this:
public abstract class ObjectPoolObject : MonoBehaviour {
public abstract void ObjectPool_Activate();
public abstract void ObjectPool_Deactivate();
public ObjectPool<ObjectPoolObject> m_pool;
}
public class ObjectPool<T> where T : ObjectPoolObject
{
public ObjectPool(CreateObjectDelegate creationMethod)
{
m_creationMethod = creationMethod;
T objectPoolObject = creationMethod();
// this is the line that gives me error CS0030: Cannot convert type `ObjectPool<T>' to `ObjectPool<ObjectPoolObject>'
objectPoolObject.m_pool = this;
}
}
Since T : ObjectPoolObject I should be able to do this...
All I need is for the ObjectPoolObject to have a reference to it's parent ObjectPool... how can I accomplish this?
EDIT:
This is the error message:
error CS0030: Cannot convert type ObjectPool<T> to ObjectPool<ObjectPoolObject>'
but since T: ObjectPoolObject it seems like it should be able to do this. its like it's saying "cannot convert a child class to a parent class..." T inherits from ObjectPoolObject... thus ObjectPool of T is analogous to a child class ObjectPool of ObjectPoolObject... Liskov substitution principle should allow me to cast a ObjectPool of T to an ObjectPool of ObjectPoolObject.
For example, I have an ObjectPool of Bullets where Bullet inherits from ObjectPoolObject. I should be able to cast it to an ObjectPool of ObjectPoolObjects, considering all the elements in the ObjectPool are ObjectPoolObjects.....
EDIT - I'm starting to understand what the problem with the cast is.... its so hard to explain, wow.
EDIT2 - The answer of defining an interface using the "in" keyword on the generic type is the correct answer for this problem. HOWEVER! I have decided that this has crossed the line of "too complex" and have decided to remove the m_pool field from the ObjectPoolObject. When you get an object from an object pool, its up to you to record which pool it came from and put it back appropriately. The m_pool field was simply dirtying up my system too much for me to justify including it.
Removing the Genericism from ObjectPool completely is also a functional solution, but it requires me to cast the return result of every ObjectPool.Get call, and I decided I didn't want that either.

You need to make your type parameter contravariant using the in modifier, which is only allowed on interfaces and delegates.
interface IObjectPool<in T> where T : ObjectPoolObject
{
}
class ObjectPoolObject
{
public IObjectPool<ObjectPoolObject> Pool { get; internal set; }
}
class ObjectPool<T> : IObjectPool<T> where T : ObjectPoolObject
{
public ObjectPool(Func<T> createObject)
{
T obj = createObject();
obj.Pool = this;
}
}

You need to look at covariance and contravariance in C# as documented here.
In short - you need to declare your class as
public class ObjectPool<**in** T> where T : ObjectPoolObject

The problem is that while T does indeed inherit from ObjectPoolObject, that hos nothing to do wether ObjectPool<T> inherits from ObjectPool<ObjectPoolObject>.
for example, take the following code:
public class Class1<T> where T : Class3, new()
{
public Class1()
{
Class3 variable1;
variable1 = new T(); // This works just fine T is or inherits from Class3
Class1<Class3> variable3;
variable3 = new Class1<Class2>(); // This will not work, while Class2 does indeed inherit from Class3,
// Class1<Class2> is still a different class from Class1<Class3>
// while their type parameters have an inheritance between them, they themselves do not.
Class1<Class3> variable2;
variable2 = new Class1<T>(); // And for just the same reason as stated above, this will not work either
}
}
To do what you're trying to do, we would have to make something more complex (and to be honest, complexity is not Always a good thing). But just for the sake of it, have a look at this:
public class AbstractObjectPool<T, T2> where T : AbstractObjectPool<T, T2> where T2 : ObjectPoolObject<T, T2>
{
public T m_pool;
}
public class ObjectPool<T> : AbstractObjectPool<ObjectPool<T>, T> where T : ObjectPoolObject<ObjectPool<T>, T>
{
public ObjectPool(Func<ObjectPool<T>> creationMethod)
{
ObjectPool<T> objectPoolObject = creationMethod();
objectPoolObject.m_pool = this;
}
}
public abstract class ObjectPoolObject<T, T2> where T : AbstractObjectPool<T, T2> where T2 : ObjectPoolObject<T, T2>
{
}
However, I wonder if (in your case) you wouldn't be better off skipping generics alltogeather and co for a simple base class:
public class ObjectPool
{
public ObjectPool(Func<ObjectPoolObject> creationMethod)
{
ObjectPoolObject objectPoolObject = creationMethod();
objectPoolObject.m_pool = this;
}
}
public abstract class ObjectPoolObject
{
public ObjectPool m_pool;
}

Generics: why can't the compiler infer the type parameter contraints? [duplicate]

Item class
public class Item
{
public bool Check(int value) { ... }
}
Base abstract class with generic type constraint
public abstract class ClassBase<TItem>
where TItem : Item
{
protected IList<TItem> items;
public ClassBase(IEnumerable<TItem> items)
{
this.items = items.ToList();
}
public abstract bool CheckAll(int value);
}
Inherited class without constraints
public class MyClass<TItem> : ClassBase<TItem>
{
public override bool CheckAll(int value)
{
bool result = true;
foreach(TItem item in this.items)
{
if (!item.Check(value)) // this doesn't work
{
result = false;
break;
}
}
return result;
}
}
I would like to know why aren't generic type constraints inheritable? Because if my inherited class inherits from base class and passes over its generic type which has a constraint on the base class it automatically means that generic type in inherited class should have the same constraint without explicitly defining it. Shouldn't it?
Am I doing something wrong, understanding it wrong or is it really that generic type constraint aren't inheritable? If the latter is true, why in the world is that?
A bit of additional explanation
Why do I think that generic type constraints defined on a class should be inherited or enforced on child classes? Let me give you some additional code to make it bit less obvious.
Suppose that we have all three classes as per above. Then we also have this class:
public class DanteItem
{
public string ConvertHellLevel(int value) { ... }
}
As we can see this class does not inherit from Item so it can't be used as a concrete class as ClassBase<DanteItem> (forget the fact that ClassBase is abstract for now. It could as well be a regular class). Since MyClass doesn't define any constraints for its generic type it seems perfectly valid to have MyClass<DanteItem>...
But. This is why I think generic type constraints should be inherited/enforced on inherited classes just as with member generic type constraints because if we look at definition of MyClass it says:
MyClass<T> : ClassBase<T>
When T is DanteItem we can see that it automatically can't be used with MyClass because it's inherited from ClassBase<T> and DanteItem doesn't fulfill its generic type constraint. I could say that **generic type on MyClass depends on ClassBase generic type constraints because otherwise MyClass could be instantiated with any type. But we know it can't be.
It would be of course different when I would have MyClass defined as:
public class MyClass<T> : ClassBase<Item>
in this case T doesn't have anything to to with base class' generic type so it's independent from it.
This is all a bit long explanation/reasoning. I could simply sum it up by:
If we don't provide generic type constraint on MyClass it implicitly implies that we can instantiate MyClass with any concrete type. But we know that's not possible, since MyClass is inherited from ClassBase and that one has a generic type constraint.
I hope this makes much more sense now.

ANOTHER UPDATE:
This question was the subject of my blog in July 2013. Thanks for the great question!
UPDATE:
I've given this some more thought and I think the problem is that you don't want inheritance at all. Rather, what you want is for all constraints that must be placed on a type parameter in order for that type parameter to be used as a type argument in another type to be automatically deduced and invisibly added to the declaration of the type parameter. Yes?
Some simplified examples:
class B<T> where T:C {}
class D<U> : B<U> {}
U is a type parameter that is used in a context where it must be C. Therefore in your opinion the compiler should deduce that and automatically put a constraint of C on U.
What about this?
class B<T, U> where T : X where U : Y {}
class D<V> : B<V, V> {}
Now V is a type parameter used in a context where it must be both X and Y. Therefore in your opinion the compiler should deduce that and automatically put a constraint of X and Y on V. Yes?
What about this?
class B<T> where T : C<T> {}
class C<U> : B<D<U>> where U : IY<C<U>> {}
class D<V> : C<B<V>> where V : IZ<V> {}
I just made that up, but I assure you that it is a perfectly legal type hierarchy. Please describe a clear and consistent rule that does not go into infinite loops for determining what all the constraints are on T, U and V. Don't forget to handle the cases where type parameters are known to be reference types and the interface constraints have covariance or contravariance annotations! Also, the algorithm must have the property that it gives exactly the same results no matter what order B, C and D appear in source code.
If inference of constraints is the feature you want then the compiler has to be able to handle cases like this and give clear error messages when it cannot.
What is so special about base types? Why not actually implement the feature all the way?
class B<T> where T : X {}
class D<V> { B<V> bv; }
V is a type parameter used in a context where it must be convertible to X; therefore the compiler should deduce this fact and put a constraint of X on V. Yes? Or no?
Why are fields special? What about this:
class B<T> { static public void M<U>(ref U u) where U : T {} }
class D<V> : B<int> { static V v; static public void Q() { M(ref v); } }
V is a type parameter used in a context where it can only be int. Therefore the C# compiler should deduce this fact and automatically put a constraint of int on V.
Yes? No?
You see where this is going? Where does it stop? In order to implement your desired feature properly the compiler must do whole-program analysis.
The compiler does not do this level of analysis because that is putting the cart before the horse. When you construct a generic, you are required to prove to the compiler that you've satisfied the constraint. It's not the compiler's job to figure out what you meant to say and work out what further set of constraints satisfy the original constraint.
For similar reasons, the compiler also does not attempt to automatically infer variance annotations in interfaces on your behalf. See my article on that subject for details.
http://blogs.msdn.com/b/ericlippert/archive/2007/10/29/covariance-and-contravariance-in-c-part-seven-why-do-we-need-a-syntax-at-all.aspx
Original answer:
I would like to know why aren't generic type constraints inheritable?
Only members are inherited. A constraint is not a member.
if my inherited class inherits from base class and passes over its generic type which has a constraint on the base class it automatically means that generic type in inherited class should have the same constraint without explicitly defining it. Shouldn't it?
You're just asserting how something should be, without providing any explanation of why it should be that way. Explain to us why you believe that the world should be that way; what are the benefits and what are the drawbacks and what are the costs?
Am I doing something wrong, understanding it wrong or is it really that generic type constraint aren't inheritable?
Generic constraints are not inherited.
If the latter is true, why in the world is that?
Features are "not implemented" by default. We don't have to provide a reason why a feature is not implemented! Every feature is not implemented until someone spends the money to implement it.
Now, I hasten to note that generic type constraints are inherited on methods. Methods are members, members are inherited, and the constraint is a part of the method (though not part of its signature). So the constraint comes along with the method when it is inherited. When you say:
class B<T>
{
public virtual void M<U>() where U : T {}
}
class D<V> : B<IEnumerable<V>>
{
public override void M<U>() {}
}
Then D<V>.M<U> inherits the constraint and substitutes IEnumerable<V> for T; thus the constraint is that U must be convertible to IEnumerable<V>. Note that C# does not allow you to restate the constraint. This is in my opinion a misfeature; I would like to be able to restate the constraint for clarity.
But D does not inherit any kind of constraint on T from B; I don't understand how it possibly could. M is a member of B, and is inherited by D along with its constraint. But T is not a member of B in the first place, so what is there to inherit?
I'm really not understanding at all what feature it is that you want here. Can you explain with more details?

Below is a scenario where the implicit nature of this behavior causes different behavior than expected:
I recognize that this scenario may seem extravagant in the amount of setup, but this is just one example of where this behavior might cause a problem. Software applications can be complicated, so even though this scenario may seem complicated, I wouldn't say that this can't happen.
In this example there is an Operator class that implements two similar interfaces: IMonitor and IProcessor. Both have a start method and an IsStarted property, but the behavior for each interface within the Operator class is separate. I.e. there is a _MonitorStarted variable and a _ProcessorStarted variable within the Operator class.
MyClass<T> derives from ClassBase<T>. ClassBase has a type constraint on T that it must implement the IProcessor interface, and according to the suggested behavior MyClass inherits that type constraint.
MyClass<T> has a Check method, which is built with the assumption that it can get the value of the IProcessor.IsStarted property from the inner IProcessor object.
Suppose someone changes the implementation of ClassBase to remove the type constraint of IProcessor on the generic parameter T and replace it with a type contraint of IMonitor. This code will silently work, but will produce different behavior. The reason is because the Check method in MyClass<T> is now calling the IMonitor.IsStarted property instead of the IProcessor.IsStarted property, even though the code for MyClass<T> hasn't changed at all.
public interface IMonitor
{
void Start();
bool IsStarted { get; }
}
public interface IProcessor
{
void Start();
bool IsStarted { get; }
}
public class Operator : IMonitor, IProcessor
{
#region IMonitor Members
bool _MonitorStarted;
void IMonitor.Start()
{
Console.WriteLine("IMonitor.Start");
_MonitorStarted = true;
}
bool IMonitor.IsStarted
{
get { return _MonitorStarted; }
}
#endregion
#region IProcessor Members
bool _ProcessorStarted;
void IProcessor.Start()
{
Console.WriteLine("IProcessor.Start");
_ProcessorStarted = true;
}
bool IProcessor.IsStarted
{
get { return _ProcessorStarted; }
}
#endregion
}
public class ClassBase<T>
where T : IProcessor
{
protected T Inner { get; private set; }
public ClassBase(T inner)
{
this.Inner = inner;
}
public void Start()
{
this.Inner.Start();
}
}
public class MyClass<T> : ClassBase<T>
//where T : IProcessor
{
public MyClass(T inner) : base(inner) { }
public bool Check()
{
// this code was written assuming that it is calling IProcessor.IsStarted
return this.Inner.IsStarted;
}
}
public static class Extensions
{
public static void StartMonitoring(this IMonitor monitor)
{
monitor.Start();
}
public static void StartProcessing(this IProcessor processor)
{
processor.Start();
}
}
class Program
{
static void Main(string[] args)
{
var #operator = new Operator();
#operator.StartMonitoring();
var myClass = new MyClass<Operator>(#operator);
var result = myClass.Check();
// the value of result will be false if the type constraint on T in ClassBase<T> is where T : IProcessor
// the value of result will be true if the type constraint on T in ClassBase<T> is where T : IMonitor
}
}

I think you're confused becuase you're declaring you derived class with TItem as well.
If you think about it if you were using Q instead so.
public class MyClass<Q> : BaseClass<Q>
{
...
}
Then how is it to be determined that Q is of the type item?
You need to add the constraint to the derived classes Generic Type as well so
public class MyClass<Q> : BaseClass<Q> were Q : Item { ... }

Because the ClassBase has a constraint on his template (should by typeof Item), you have to add this constraint to MyClass too.
If you don't do this, you could create a new instance of MyClass, where the template isn't a type of Item. When creating the base class, it will fail.
[edit]
Hmm now a re-read your question, and I see your code does compile? Ok.
Well, im MyClass you don't know the basetype of this.items, so you can't call the Check method.
this.items is of the type IList, and in your class, TItem isn't specified, thats why the class doesn't understand the Check method.
Let me counter your question, why don't you want to add the constraint to your MyClass class? Given any other class type as template to this class, would result in an error. Why not prevent this errors by adding a constraint so it will fail compiletime.

C# Generics, interfaces and inheritance

I've two interfaces:
public interface IAmA
{
}
public interface IAmB<T> where T : IAmA
{
}
And two classes implementing these interfaces like this:
public class ClassA : IAmA
{
}
public class ClassB : IAmB<ClassA>
{
}
When trying to use these classes as shown:
public class Foo
{
public void Bar()
{
var list = new List<IAmB<IAmA>>();
list.Add(new ClassB());
}
}
I get this compiler error:
cannot convert from 'ClassB' to 'IAmB<IAmA>'
I know I can make the compiler happy using:
public class ClassB : IAmB<IAmA>
{
}
But I need to be able to be the Type parameter for IAmB<> in ClassB an implementation of IAmA.

The quick answer is that you can do what you ask by declaring the type parameter of IAmB<T> as covariant, only if the type is used as a return type:
public interface IAmB<out T> where T : IAmA
{
T SomeMethod(string someparam);
}
out T means that you can use a more specific type than then one specified in the constraints.
You won't be able to use T as a parameter. The following won't compile:
public interface IAmB<out T> where T : IAmA
{
void SomeMethod(T someparam);
}
From the documentation
You can use a covariant type parameter as the return value of a method that belongs to an interface, or as the return type of a delegate. You cannot use a covariant type parameter as a generic type constraint for interface methods.
This isn't a compiler quirk.
Assuming you could declare a covariant method parameter, your list would end up containing some objects that couldn't handle an IAmB<IAmA> parameter - they would expect an input of ClassA or more specific. Your code would compile but fail at runtime.
Which begs the question - why do you want to use IAmB<ClassA> ?
You should think about before using this though, as there may be other, more suitable ways to address your actual problem. It's unusual to use a generic interface implementing a concrete type but trying to use it as if it were implementing another interface.
You can check the MSDN documentation's section on Covariance and Contravariance as well as Eric Lippert's an Jon Skeet's answers to this SO question: Difference between Covariance and Contravariance

Fast answer : make the generic type covariant (see msdn) in your interface
public interface IAmB<out T> where T : IAmA
{
}
this will resolve the compiler problem.
But this won't answer the why asked by Panagiotis Kanavos !

The trick is making the type constraint T on IAmB<T> covariant, with the out keyword:
public interface IAmB<out T> where T : IAmA
{
}
This allows you to use a more specific type than originally specified, in this case allowing you to assign an IAmB<ClassA> to a variable of type IAmB<IAmA>.
For more information, see the documentation.

I just tell why this error reported.
if your IAmB has a method
public interface IAmB<T> where T : IAmA
{
void foo(T p);
}
public class ClassB : IAmB<ClassA>
{
void foo(ClassA p)
{
p.someIntField++;
}
}
and we have another class
public class ClassC : IAmB<ClassA2>
{
void foo(ClassA2 p)
{
p.someOtherIntField++;
}
}
and we assume List<IAmB<IAmA>>.Add(T p) implement like this
IAmA mParam = xxxx;
void Add(IAmB<IAmA>> p){
p.foo(mParam);
}
thinking all compile OK. you pass a ClassB instance to List.Add, it becomes
void Add(IAmB<IAmA>> p){
//p is ClassB now
p.foo(mParam);//COMPILER CAN NOT MAKE SURE mParam fit ClassB.foo
}

It can be solved using Contravariance and Covariance.
public interface IAmA
{
}
**public interface IAmB<out T> where T : IAmA
{
}**
public class ClassA : IAmA
{
}
public class ClassB : IAmB<ClassA>
{
}
public class Foo
{
public void Bar()
{
var list = new List<IAmB<IAmA>>();
**list.Add(new ClassB());**
}
}
Now you don't get compiler error. Compiler is happy.

Partially applying generics for type constraints

I currently try to construct a generic interface that every (generic) class deriving it will have a method accepting a delegate that accepts the type parameter and returns another class of the same type, with only another type parameter.
I tried the following:
public interface GenericInterface<out T, out SomeDerived>
where SomeDerived<T> : GenericInterface<T, SomeDerived>
{
SomeDerived<NT> bind<NT>(bindee<T, NT, SomeDerived<NT>> bindFunc);
}
public delegate AnotherDerived<T2> bindee<in T1, out T2, out AnotherDerived>(T1 param)
where AnotherDerived<T2> : GenericInterface<T2, AnotherDerived>;
public class Derived<T> : GenericInterface<T, Derived>
{
Derived<NT> bind<NT>(bindee<T, NT, Derived<NT>> bindFunc);
}
But it fails to compile and I get this error:
Invalid token '<' in class, struct, or interface member declaration
What is the correct design in such case?
EDIT:
I understand the syntatic reason for the compiler errors. You cannot apply a generic type argument a parameter in a where clause.
I am asking what is the best way to mimic such behavior.

I'll go out on a limb here and say what you're trying to do here with the Generic is impossible; I'll remove if someone thinks I'm wrong.
So lets start with this
interface IFoo<T> where T : IFoo<T>{}
class Foo<T> : IFoo<T> where T : IFoo<T>{}
class Bar<T> : Foo<T> where T : IFoo<T>{}
Lets try to instanciate this;
var foo = new Foo< Bar< ....errr what now? ad infinitum...
So to fix this, you need to redesign so you're classes looks more like this:
interface IBase {}
interface IFoo<out T> where T : IBase { }
class Foo<T> : IFoo<T> where T : IBase { }
which then allows:
IFoo<IBase> foo = new Foo<Base>();
[Addendum]
You can have function level generics that let you get around problems like these...
interface IFoo<out T> where T : IBase
{
IFoo<TBind> Bind<TBind>(Action<T, TBind> bindFunc) where TBind : IBase;
}