Your proposed syntax is interesting. I find it confusing that the
constraint class TRef is automatically matched up with the type
parameter TRef without a where clause, though. Type parameter names are
normally local to the generic class/method where they're declared - one
class's TKey might have nothing in common with another class's TKey.
I've been thinking about possible extensions too. I'm so frustrated by
the power that generics *almost* have that I might even try to hack
these into Mono's compiler to test them. Here are a couple of my
ideas...
Signature constraints:
public T Sum(params T[] items)
where T has static T operator +(T left, T right)
{
T result;
foreach (T item in items) result = result + item;
return result;
}
"has" can be a contextual keyword like "where". The constraint passes
if the type argument has an accessible method with the given signature,
which can be an instance method or static method (including operators).
Implicit interface constraints:
public interface IContainer<T>
{
void Add(T item);
void Remove(T item);
}
public void AddItemToContainer<TCont,TItem>(TCont container, TItem
item)
where TCont : implicit IContainer<TItem>
{
container.Add(item);
}
"implicit" is already a keyword, but this is a new use. The constraint
passes if the type argument implements the given interface, or if it
*could* implement the given interface (i.e. if you could add it to the
class's definition and the class would still compile). Basically, this
is shorthand so you don't have to write a signature constraint for each
method of the interface.
TCont here could be any type that has an Add(TItem) and Remove(TItem)
method. You couldn't pass "container" to a method that expected an
IContainer<TItem> parameter, since it doesn't necessarily implement the
interface for real, but you could still call the Add and Remove
methods.
One problem with this implicit interface syntax is that interfaces
can't have static methods, and IMO if static methods in an interface
were allowed, they should work like regular static methods; they
shouldn't be part of the interface contract.
Perhaps static interfaces? Something like this:
static interface IArithmetic<T>
{
static T operator +(T left, T right);
static T operator -(T left, T right);
...
}
Such an interface wouldn't be very useful outside of those implicit
interface constraints, though.
Jesse
Jethro Guo wrote:
C++ template use constraint by signature,It's very flexible to programmer but
complex for complier, and at most time programmer can not
get clear error message from complier if error occur. C# generic use
constraint by type,complier is relaxed, but it is very limited to
programmer.Is there a way to get merits of both?
Maybe the following way can achieve this purpose :
//First add a keyword "constrant" to modify class or struct just like
keyword "abstract"
//Used to define constrant, so the meta data can be treat same as common
class.
constrant class TRef : ISomeInterface
{
//Constructors
public TRef();
public TRef(int i);
//Methods
public static bool operator ==(TRef t1, TRef t2);
public static bool operator +(TRef t1, TRef t2);
public void Method1();
public void Method2(TRef t, int i);
//Properties
public int Property1{get;set;}
public int this[int i]{get;}
}
constrant struct TValue: ISomeInterface
{
//Constructors
public TValue();
public TValue(int i);
//Static Methods
public static bool operator ==(TValue t1, TValue t2);
public static bool operator +(TValue t1, TValue t2);
public void Method1();
public void Method2(TValue t, int i);
//Properties
public int Property1{get;set;}
public int this[int i]{get;}
}
//GenericClass use TRef,TValue as normal class,compiler can give clear error
message
public class GenericClass<TRef,TValue>
//Note here use constrant class or struct directly
//"where" statement is not needed now
{
public void sample()
{
//here just treat TRef,TValue as normal class
TRef refObj = new TRef();
TRef refObj2 = new TRef(1);
TRef refObj3 = refObj + refObj2;
TValue valueObj = new TValue(100);
TValue valueObj2 = new TValue(10);
if (valueObj == valueObj2)
{
valueObj.Method1();
valueObj2.Method2();
}
int i=refObj3.Property1;
int j=valueObj2[0];
}
}
public class UseGenericClass
{
public void Test()
{
//Compiler will check:
//RealClass includes all signatures of TRef, but do not force
RealClass inherited from TRef;
//RealValue includes all signatures of TValue
GenericClass<RealClass,RealValue> obj=new
GenericClass<RealClass,RealValue>();
}
}