Develop Reference

C#: Is it possible to have multiple generic constraints on the same generic variable?

To illustrate it with an example:
??? public class Foo<T> where T:(ClassA || ClassB){}
Is it possible to restrict T for a number of unrelated classes in an or relationship (T is either ClassA or ClassB, but nothing else) or the only way to achieve this is to either
make ClassA and ClassB both implement the same interface
have both classes derive from the same base class
and use these as constraints?
So, to make things clear: my question does not concern whether you can have n number of generic constraints for n number of variables, I want to know if I can have n number of constraints for the very same variable.

I would implement a different type of logic for both and return the appropriate. This, of course, can be done using interfaces.
Even if you can promise that both types have the exact same members, the compiler has no way of verifying this.
By having both classes implement the same interface, you make that guarantee to the compiler that they do share at least the members of the interface, and those members are available to the generic class to use. This is the reason interfaces exist as well as the whole point of generics.

No, and if you think about it, it wouldn't be very useful.
The purpose of applying generic constraints is to ensure that the code is able to do certain operations on the type. E.g. the new() constraint ensure you can do new T(), which is not possible for an unconstrained type. But applying an "or" constraint does not provide any useful static guarantees for T, so you cant really use it for anything.
You can have multiple constraints for a single type variable though, but they are "and" constraints, i.e. they all have to be fulfilled.

If I get it right, you basically want to evaluate an expression as part of the constraint and to my best knowledge it isn't possible.
Type parameters can have multiple constraints though, just not as an expression. See here from this example:
class EmployeeList<T> where T : Employee, IEmployee, System.IComparable<T>, new()
{
// ...
}
Here T sure has multiple constraints, but not as an expression.
In this case though you might wish to take a look at your design to eliminate the need of your question.

Short answer is: No, you can't. Others already explained why, but in short you would lose the type safety that comes with generics.
If for whatever reason you still needs this, there is a solution to use method overloads and the compiler does the rest.
public void Foo<T>(T instance) where T : ClassA
{
GenericFoo(instance);
}
public void Foo<T>(T instance) where T : ClassB
{
GenericFoo(instance);
}
private void GenericFoo(object instance)
{
// Do stuff
}

Why can't a static and non-static method share the same signature?

C# provides following signature characteristics to be used while function overloading.
We know that for overloading takes into consideration only arguments; their number and types, but the objective of polymorphism is to provide same name but different usage depending upon calling strategy.
If I have a class containing two methods with the same name and signature, while one is static and another is not, C# compiler throws an error; "Class already defines a member called 'foo' with the same parameter types".​The call to both the methods are going to be different; one with the object name and the static one with a class name. Hence there is no ambiguity with calling strategy. Then why does it throw an error?
class Example {
public void foo() { }
public static void foo() { }
}
class Program
{
static void Main(string[] args)
{
Example e = new Example();
e.foo();
}
}

Reason why it is throwing an error is that static methods can be called from non-static methods without specifying type name. In this case, compiler won't be able to determine, which method is being called.
public class Foo()
{
public static void MyMethod() {};
public void MyMethod() {}
public void SomeOtherMethod()
{
MyMethod(); // which method we're calling static or non-static ?
}
}
EDIT
Just found this SO post regarding your case. You might want to check it also.

This error occurs because this is how the behavior is defined in the C# Language Specification. Any "ambiguous" usage (or ways to disambiguate such) is irrelevant, although such reasoning and edge-cases may have led the designers to not explicitly allow such a differentiation .. or it might simply be a C# codification of an underlying .NET CLI/CLR restriction1.
From "3.6 Signatures and overloading" in the C# specification (and in agreement with the linked documentation), formatted as bullets:
The signature of a method consists of
the name of the method,
the number of type parameters, and
the type and kind (value, reference, or output) of each of its formal parameters ..
Method modifiers, including static, are not considered as part of the method signature here.
And, from "1.6.6 Methods" we have the restriction and an agreeing summary:
The signature of a method must be unique in the class in which the method is declared. The signature of a method consists of the name of the method, the number of type parameters and {the number, modifiers, and types of} its parameters..
This restriction applies before (and independently of) the method being considered for polymorphism.
Also, as a closing note: instance methods must be virtual or accessed through an interface to be run-time polymorphic in C#. (Both method hiding and method overloading are arguably a form of compile-time polymorphism, but that's another topic..)
1There is support for this simply being the result of a restriction of the .NET CLI/CLR itself that is not worth bypassing (ie. for interoperability reasons). From "I.8.6.1.5 Method signatures" in ECMA-335:
A method signature is composed of
a calling convention [CLS Rule 15: "the only calling convention
supported by the CLS is the standard managed calling convention"],
the number of generic parameters, if the method is generic,
[omitted rule]
a list of zero or more parameter signatures—one for each parameter of the method—
and,
a type signature for the result value, if one is produced.
Method signatures are declared by method definitions. Only one constraint can be added to a
method signature in addition to those of parameter signatures [CLS Rule 15: "The vararg constraint is not part of the CLS"]:
The vararg constraint can be included to indicate that all arguments past this point are
optional. When it appears, the calling convention shall be one that supports variable
argument lists.
The intersection between the C#/CLS and ECMA signature components is thus the method name, "the number of generic parameters", and "a list of zero or more parameter signatures".

I feel your question is "why did the standard choose to forbid declaring two methods that differ only by the static keyword?", and therefore the answer "because the standard says so" does not look appropriate to me.
Now, the problem is, there could be any reason. The standard is the Law, and it can be arbitrary. Without the help of somebody who participated to the language's design, all we can do is speculate about the reasons, trying to uncover the spirit of the Laws.
Here is my guess. I see three main reasons for this choice:
Because other languages say so.
C++ and Java are inspirational languages for C#, and it makes sense to observe the same overloading rules as those languages. As to why it is this way in these languages, I don't know. I found a similar question on SO about C++, although no answer is given as to why it is this way (outside of "the standard says so").
Because it creates ambiguity that need to be resolved.
As others and OP noted, allowing the same signatures excepted for the static keyword forces the user to call the methods in an unambiguous way (by prefixing the class name or the instance name). This adds a level of complexity to the code. Of course this can already be done with fields and parameters. However some don't agree with this usage and prefer to choose different names (prefixing the fields with _ or m_) for the fields.
Because it does not make a lot of sense in OOP.
This is really my understanding here, so I could be completely wrong (at least #user2864740 thinks that the argument is dubious -- see comments), but I feel like static members are a way to introduce "functional programming" in OOP. They are not bound to a specific instance, so they don't modify the internal state of an object (if they modify the state of another object, then they should be a non-static method of this other object), in a way they are "pure".
Therefore I don't understand how a "pure function" could be semantically close enough of a regular object method so that they would share the same name.

The same question was asked to Eric Gunnerson, who worked on the C# language design team, and his answer was:
It is true that there would be no ambiguity between the two functions as far as a compiler is concerned. There would, however, be a considerable potential for confusion on the part of the user. It would be tough to find the right method in documentation, and once you did, hard to be sure that you are calling the right version (ie you could accidentally call the static version when you wanted the instance version).
Therefore, the reason it is not allowed is by design.

i) Problem hypothesis - obtain the following behavior :
Be able to call a static method off of a class: e.g. MyClass.MySpecialMethod()
Also be able to call a non-static method with the same return type, name and arguments off of an instance of the same class: e.g. instanceOfMyClass.MySpecialMethod()
ii) Context :
Reproduce the behavior inside an application that uses Dependency Injection.
Most of today's programming uses DI - it is almost an anti-pattern to call a non-static method off of a direct instance of a dependency (without that dependency having been previously injected with DI).
iii) Solution :
class Program
{
static void Main(string[] args)
{
// instead of class initialization we would have these registrations, e.g.:
// diContainer.Resolve<IMyApplication>().With<MyDIApplication>();
// diContainer.Resolve<ITerminator>().With<Terminator>();
IMyApplication app = new MyDIApplication(new Terminator());
app.Run();
}
public interface IMyApplication { void Run(); }
public class MyDIApplication : IMyApplication
{
private readonly ITerminator terminator;
public MyDIApplication(ITerminator terminatorDependency)
{
this.terminator = terminatorDependency;
}
public void Run()
{
terminator.Terminate(); // instance method call
Terminator.Terminate(); // static method call
}
}
public interface ITerminator { void Terminate(); }
public class Terminator : ITerminator
{
public static void Terminate() => Console.WriteLine("Static method call.");
void ITerminator.Terminate() => Console.WriteLine("Non-static method call.");
}
}
Conclusion:
Yes, the signatures of the two Terminate methods are not identical, because the non-static method is an explicit implementation of the interface which does not conflict with the static method,
But in truth, when using this solution in the context of dependency injection, what we really care about is the outcome, not the plumbing - which is that we managed to call a static method off a class, with practically the same return, name and args as a non-static method off an instance of that class injected with DI.

Check out this simple pseudo-code:
class A
{
public void B(){...}
public static void B(){...}
}
...
A A = new A();
A.B(); // <== which one is going to be called?

Parameter constraints - call method to check type in constraint?

I have a method with a generic parameter:
internal void DoSomething<T>(T workWithThis)
{
}
I now want to constrain this method to only accept parameters which inherit one of a few interfaces I'd like to specify. However I have not yet found a way to it. What I'd like looks like this:
internal void DoSomething<T>(T workWithThis) where T : ISomething | ISomethingElse
{
}
Obviously this is not working, so I tried it with a static method to check the Type of T:
public static bool CheckType(Type t)
{
return */check here*/
}
internal void DoSomething<T>(T workWithThis) where T : CheckType(typeof(T))
{
}
Obviously this is not going to work either. The question is why? Why is the compiler preventing me from doing that, based on my understanding there is no reason for it not to work

Why is the compiler preventing me from doing that, based on my understanding there is no reason for it not to work
The compiler is preventing you from doing it because you're trying to do something which isn't supported by C# as a language. The syntax you're trying to use does not comply with the productions in section 10.1.5 of the C# spec.
C# as a language simply does not support the scenario you require.
Now as for why the language doesn't allow this sort of flexibility - that comes down to the normal balancing act of:
How many developers would benefit from this and how much
Extra burden on other developers to understand a more complicated language
Resources (primarily within Microsoft) required to design the language feature, implement and test it
Oh, and of course this isn't just C# - the CLR would have to support such a restriction as well, and it would at least encourage other CLR languages to understand it too.
I suggest you solve this by having two separate methods. Note that they can't just be overloads of generic methods, as overloads cannot differ only by generic type constraints. If you don't mind about boxing for value types implementing the interface, you could overload with:
internal void DoSomething(ISomething something)
{
}
internal void DoSomething(ISomethingElse somethingElse)
{
}
... although then if you pass in a value where the expression is a type implementing both interfaces, you'll end up with overload ambiguity.
Alternatively, just give the two methods different names.

The compiler has to verify all the constraints at compile time, and cannot call a method to do so.
The only things you can specify in the where constraints are:
new() - require a parameterless constructor
class - must be a reference type
struct - must be a value type
SomeBaseClass
ISomeInterface
T : U - must be, inherit from, or implement one of the other generic parameters
See the C# Programming Guide - Constraints on Type Parameters for more information.
As for why, you should never have to answer "I see no reason for this to work". You have to start in the opposite direction, "Why should this work", and then come up with enough plausible and realistic scenarios and requirements to make it worthwhile to implement. See Minus 100 Points by Eric Gunnerson.
To fix this in your code, you should derive both interfaces from a common interface, and add a constraint on that instead.
If the two interfaces have nothing in common, then I question the benefit of actually adding a constraint in the first place.
For instance, if your code is going to call a method on the objects being used with the generic type/method, then obviously both interfaces have to have the same notion about what that method is, and the only way to do that would be for the method to be defined in a common base interface. That the two interfaces happen to have the same method or property declared, with the same signature, does not make it the same method.
Having said that, are you sure you even need generics here?
How about just declaring two methods, each taking one such interface?
internal void DoSomething(ISomething workWithThis)
internal void DoSomething(ISomethingElse workWithThis)

The compiler uses the generic constraint to determine what operations is available on T within the generic method - so allowing an or expression would not be type safe. For example you have two interfaces IFirst and ISecond:
public interface IFirst
{
void First();
}
public interface ISecond
{
void Second();
}
internal void DoSomething<T>(T workWithThis) where T : IFirst or ISecond
{
//How to call this method if the type is ISecond
workWithThis.First();
//How to call this method if the type is IFirst
workWithThis.Second();
}

You can define an empty interface that holds all of them.
Remember, that in C# interfaces can have multiple inheritance.
For example:
public interface IHolder : ISomething, ISomethingElse
{
}
and for generic
internal void DoSomething<T>(T workWithThis) where T : IHolder
{
}

Are constraints taken into account while resolving generic method signature?

Assuming this:
public class GenericMethods
{
public T Method<T>() where T : struct
{
// Do something specific to a struct
}
public T Method<T>() where T : class
{
// Do something specific to a class
}
}
Is somehow invalid at compile time, because the two method take the same parameters. But would there really be a moment that the two methods would collide since the constraints are mutually exclusive? Would it be possible while resolving T that the software would be unable to choose one of the two methods?
How would someone make two generic methods of the same name and parameters that would differ if the generic type is a struct or a class?

No. Contraints are not taken into account. Neither are return types. This will not compile, and is not legal C#.
This is documented in 3.6 of the C# language spec:
The signature of a method specifically does not include the return type, the params modifier that may be specified for the right-most parameter, nor the optional type parameter constraints.
While the two methods are "logically" distinct, and couldn't conflict, as the constraints should make it clear which is being called, the C# language doesn't support this. The language designers decided that this was the way they chose to implement the rules for C#.

And you might also have a method like
public MyClass Method<T>()
{
// Do something specific to a myclass
}
so the compiler wouldn't have an unambiguous choice.

Enum TryParse with base class qualifier

I have an enum (let's say DemoEnum) and I want to parse a value to this enum. I am writing
DemoEnum value;
if(DemoEnum.TryParse("input", out value))
{
this.Value = value;
}
Now the resharper suggests me, to use the base class qualifier.
I just want to know what's the benefit of using the base class qualifier?

Generally, it is a good idea to use the most generic solution possible.
DemoEnum.TryParse("input", out value)
Is the same call as (you're just making the static call from an inherited class rather than the base class):
Enum.TryParse<DemoEnum>("input", out value)
Using the base class qualifier (Enum) instead of your specific enum (DemoEnum) would insulate you from possible side effects of changing DemoEnum in the future. The reality is that you're really only going to run into issues if you change DemoEnum to a class without changing the name.
This is generally a larger issue when using classes (and ReSharper will give the same guidance in those situations).

The TryParse() method is a static method defined in the Enum class. Since your enum inherits everything from the Enum class, it also "inherits" static members. It's not true inheritance, the static members are just visible from the class.
The other answers are wrong in that some special translation is being done for you. All you are doing is accessing the static member from a derived class since all static members are accessible through your enum. The type of the identifier that you are accessing the static method from has no bearing at all on what the generic parameters are, only what the compiler is able to infer from them (or you explicitly provide).
To illustrate my point, consider these two enums:
enum First { A, B }
enum Second { A, B }
First firstVar;
Second secondVar;
// note we're using the `First` name
First.TryParse("A", out firstVar); // valid, firstVar <= First.A
First.TryParse("B", out secondVar); // still valid, secondVar <= Second.B
// is equivalent to
Enum.TryParse<First>("A", out firstVar); // generic type is inferred from type of firstVar
Enum.TryParse<Second>("B", out secondVar); // generic type is inferred from type of secondVar
What ReSharper is telling you is that you should be accessing the static member from the class that defined actually the member. Why should you do this?
Consider what would happen if your derived type defined a static member with the same exact name. (it's not possible in this case with enums but applicable to classes in general) What would happen to your code then? Any code that accessed the static member through the derived class will take on the new value and you will probably get no new warning about it. This may or may not be desired behavior so ReSharper is preemptively warning you that you should use the actual class that defined it (the base).

Looks like Resharper is suggesting you use Enum.TryParse - http://msdn.microsoft.com/en-us/library/dd783499.aspx
I bet if you look at the IL... DemoEnum.TryParse is just doing a base.TryParse

When you write DemoEnum.TryParse, the compiler transforms it to Enum.TryParse<DemoEnum>. There is no functional difference, and you don't really need to be insulated from possible side effects because you can't define methods in an enum type, so TryParse can't be redefined. My best guess is that it's a style preference.