C# Generic Constraint Improve Way (Jethro Guo)

[Guest]

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>();
}
}

 

[Nicholas Paldino [.NET/C# MVP]]

Jethro,

No, right now, there is no way to get a constraint on a signature. MS
intentionally decided to work slowly with the constraint system to see what
the needs would be, so that they wouldn't make an error early on.

Also, the reason C++ can use constraints by signature easier than .NET
is that templates are a compile-time feature. With .NET, it is implemented
in the runtime, so it is a much more difficult thing to do (although not
impossible).

Hope this helps.

 

[Jesse McGrew]

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

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>();
}
}

 

[=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=]

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;
}

Other possible signature constraints:

where T has new(String session)
where T has static T Parse(String value)

the new(String) constraint would be irksome as AFAIK it would match any
constructor that takes a string, not necessarily one that is named
"session" or has the same meaning. This is clearly what interfaces are
about, documented contract, but then interfaces doesn't allow you to
construct new instances of any type of object.

I've needed the first of those two and had to hack it with the Activator
object. Doable but doesn't seem in the spirit of generics.

<snip>

 

[Jesse McGrew]

Lasse Vågsæther Karlsen wrote:
[...]

Other possible signature constraints:

where T has new(String session)
where T has static T Parse(String value)

the new(String) constraint would be irksome as AFAIK it would match any
constructor that takes a string, not necessarily one that is named
"session" or has the same meaning. This is clearly what interfaces are
about, documented contract, but then interfaces doesn't allow you to
construct new instances of any type of object.

I think I'd prefer:

where T : new(String session)

Just because it matches the existing syntax.

As far as matching a constructor that has the same meaning, you could
define an empty interface and use it to mark the classes that do what
you want:

where T : new(String session), IConstructWithSessionString

I've needed the first of those two and had to hack it with the Activator
object. Doable but doesn't seem in the spirit of generics.

You're in good company, though... even when you use the default
constructor constraint, new T() is compiled as a call to
Activator.CreateInstance<T>() anyway. All you get with the constraint
is compile-time verification that the call will succeed.

Jesse