dotnet clr: Hi,

Extras from ECMA standard, 3rd edition:

"If an overridden generic method has one or more constraints on its generic
arguments then:
• ...
• Any such constraint on a generic argument specified by the overriding
method shall be no more restrictive than the constraint specified by the
overridden method for the same generic argument;"

It's not quite clear to me what means "no more restrictive".

I thought that it's about the subtyping relation. This would mean that,
assuming B is a subclass of A, it's alright if "void m<(A) X>()" overrides
"void m<(B) X>()" as A is not more restrictive than B ... However, such an
example is rejected by the verifier.

After looking at the C#2.0 Spec, I think that, relative to a given generic
parameter, the verifier checks that either the overriding method has no
constraint or has the "same" constraint. This would explain why the above
example is rejected.

Thank you.

[quoted text, click to view]

Well, I assumed that this is about constraints on base class methods, like
here:

class A {
public virtual void Foo<T>() where T: ISomething {
}
}

class B : A {
public override void Foo<T>() {
}
}

This code compiles. What I thought the paragraph was about was that when I
decided to add constraints to the overridden method in B as well, that
these constraints couldn't be more restrictive than those on the
overridden method. But when I tried to test this by changing the method
signature of B.Foo to this:

public override void Foo<T> where T: ISomething, new()

I found that this isn't allowed at all - the compiler just says
"Constraints for override and explicit interface implementation methods
are inherited from the base method so cannot be specified directly." So
now I have to admit I really have no idea from the top of my head what
this paragraph is talking about.


Oliver Sturm
--
Expert programming and consulting services available

Thanks Oliver for the answer.

[quoted text, click to view]

yes, because the constraint is inherited. This can be seen also in the
bytecode where
B::Foo looks B::Foo<(ISomething) T>()

[quoted text, click to view]

but you're more restrictive here by adding "new()". anyway, even if you are
not more restrictive, the verifier rejects.

[quoted text, click to view]

I really think that this "no more restrictive than" has to do with the
subtyping relation, BUT it's not currently implemented like that in the
verifier (Version 2.0.50215.44).

[quoted text, click to view]

Oliver, you were referring to C# while I was actually pointing to CIL
bytecode.

In the bytecode, you are allowed to write the same constraint in the
overriding method or to write none (which is the same as writing object). At
least, this is allowed by the current verifier ... although ECMA states that
it shall allow more.

[quoted text, click to view]

What I really wanted to say with my post is that nothing seems to be
rejected on the basis of being more or less restrictive in a derived class
- the message says that putting constraints on overridden methods in
derived classes is outright forbidden. That's why I said I don't
understand the paragraph because it really seems to specify something
completely useless.


Oliver Sturm
--
Expert programming and consulting services available