We Keep Coding

What is the goal of Where in c#?

i have this code:
Task NavigateToAsync<TViewModel>() where TViewModel : ViewModelInteres;
i dont understand the goal of where, what is the goal?,
can someone explain to me what it is for, Is it mandatory to use the reserved word WHERE?

It is not mandatory at all. You would use where when you want to apply a constraint on the types of your generics.
Some examples:
class MyGeneric<T> where T : class {...}
T here can only be a class (no structs, like int, byte etc.), this makes it possible to handle better nullable types, for example.
class MyGeneric<T> where T : notnull {...}
T can be struct or class, but will never be null.
class MyGeneric<T> where T : new() {...}
T is a class that can be instantiated with an empty constructor. Useful if you want to have generic fabrics.
interface Animal { public int nrPaws {get;} }
class MyGeneric<T> where T : Animal {...}
T must implement the interface Animal. In this way you can control the methods you can call from MyGeneric.
where is generally very handy when you want these kind of checks to be done at compile-time rather that throwing error during run-time.

it constrains what types can be used for TViewModel

Constrain interface implementations to structs?

An interface in C# can inherit another interface, e.g.
interface IFoo : IComparable { }
On the other hand, the following declaration is illegal:
interface IBar : struct { } // Invalid syntax
Is there any way an interface can be declared so that the implementing type is constrained to be a struct?

Is there any way an interface can be declared so that the implementing type is constrained to be a struct?
No, that is currently not possible and neither is the inverse (ensuring an interface is implemented by a class).
As far as documentation goes the closest thing I was able to find was this Interfaces, Interfaces (c#), Inheritance - Interfaces. I doubt there will be anything on an official MS site simply because (in most cases) there is no documentation on non-existing features (ignoring feature requests or features in progress) and this could be considered a non-existent feature.
Closest excerpt I could find
A class or struct can implement multiple interfaces. ...

Actually, thanks to this splendid comment by user #Evk, I realized that it is almost possible to constrain the implementation of an interface to be a struct (or analogously, a class).
The interface could be implemented as a generic interface, where the generic type parameter is constrained to be a struct that implements the interface itself:
interface IBar<T> where T : struct, IBar<T> { }
Now I can declare a struct that implements IBar:
struct BarStruct : IBar<BarStruct> { } // Works fine.
But, I cannot declare a class that implements IBar in the same way, since the generic type parameter is restricted to be a struct:
class BarClass : IBar<BarClass> { } // Will not compile!
However, it is not a waterproof approach: as user #Igor points out in the comment below, the following will still compile:
class BarClass : IBar<BarStruct> { }

You can not declare interface of struct, because classes and structs can only implement the interfaces. But you can declare interface with generic parameter as struct:
interface IBar<T> where T : struct
{
void Foo(T val); // T always be struct
}
And implement this interface:
class Bar : IBar<int>
{
public void Foo(int val) { }
}

Rationale after the "literal" expression `where T : class` in C#

In C#, one is allowed to write:
public class Foo<T> where T : class {
}
And according to the C# specifications, this means that:
The type argument must be a reference type; this applies also to any class, interface, delegate, or array type.
Some are of the opinion that the literal statement T : class is confusing, one could see it as.
The type argument must be a class type. So interfaces and delegates are not allowed. (wrong)
Where for instances interfaces and delegates are not allowed. I'm wondering if the C# design team considered this and why they didn't introduce a constraint like:
where T : reference
(Or another keyword that is more precise). What was the rationale to use : class instead?

They wanted to stick to a keyword that was already present in the language. Surely reference or referencetype would be more precise.
Similarly, it is called where T : struct, not valuetype (or nonnullablevaluetype), even if both structs and enums are value types that can be used for T in that case. Also note that the special struct Nullable<> is not allowed if the constraint where T : struct was used.

where T: class
reads
where T: <reference type>
I'm not sure why it was called class, though. Someone who was sitting through the language team's meetings on that one might have to chime in.

Class constraint must come before any other constraints

I am attempting to create the following class name signature:
public class MyClass<T> where T : struct, MyBase
(I am using struct to constrain to Enums)
I am getting error
The class type constraint 'MyBase' must come before any other constraints
I understand the message, however, rearranging the code I cannot get past that or some other syntax error. How can I fix that line if at all?
If I have to, I will remove struct.
Thank you

Constraints are "and-ed" together; all the constraints must be satisfied.
Under what circumstances can T be both a non-nullable value type and also be implicitly convertible to the class MyBase via identity, boxing or reference conversion?
There are no such circumstances, so there is no possible type argument that will satisfy T's constraints. Rather than letting you define a set of constraints that cannot be met, the compiler simply disallows it. You cannot state that you require both the struct constraint and a class type constraint.
I am using struct to constrain to Enums
That illustrates my point. Since there are no enums that inherit from MyBase, the constraint could not possibly be met.
Can you describe for me what you thought this meant? For example, did you think that it meant "any non-nullable value type or any type that is convertible to MyBase"? I am interested to learn why people believe false things about C# so that I can try to improve it.
UPDATE: Ah, I see -- MyBase is intended to be the base class of MyClass<T>, not the base class of T. In C#, it goes:
class [class name] < [generic type parameters] >
: [base classes and interfaces]
where [type parameter] : [constraints]
You have to put the base classes and interfaces before the constraints, otherwise the compiler thinks that they are the constraints.

Did you mean class MyClass<T> : MyBase where T : struct?

You're defining <T> as two different types.
struct is a value type where as MyBase is a class referring to a reference type.
It's not something that is interchangeable.
In this case it would be either:
public class MyClass<T> where T : struct
or
public class MyClass<T> where T : MyBase
Here is so more information regarding generics and how to use them.

If T must be a struct, it can't inherit from any other type... Value types don't support inheritance.

Not 100% sure on this, but a quick check of MSDN comes up with this where (generic type constraint) (C# Reference):
public class MyClass<T, U> where T : MyBase where U : struct
Not sure that's what you're looking for though.

Implementing IEquatable<T> where T is an interface

I have a domain model that is trivially represented by the following.
IMyInterface
ClassA : IMyInterface
ClassB : IMyInterface
What I want is to implement IEquatable in such a way that I can write code something like.
if(dynamicallyCreatedInstanceOfClassA == dynamicallyCreatedinstanceOfClassB)
{
// Do something relevant
}
My first inclination was to have IMyInterface implement IEquatable but of course I can't actually do the implementing in IMyInterface. I would have to do that in ClassA and ClassB. What strikes me as wrong with this solution is that the implementations of IEquatable in ClassA and ClassB will be exactly, line for line the same. Is there an elegant way to accomplish this? When ClassC comes along I don't want to have to copy and past 50 lines of duplicated IEquatable code.
I have considered using an abstract base class instead of an interface, but in this scenario IMyInterface really just describes actions the class will perform and not what the class is. ClassA and ClassB don't share many similarities except they can both perform the actions in the IMyInterface contract.
Any insights are helpful, and thank you for your time.

Instead of implementing IEquatable<T>, could you perhaps implement IEqualityComparer<T> in a separate class? In most cases where you're interested in equality you can specify a comparer instead, and I suspect it'll be cleaner that way.

Based on your question it seems like you know what the Equals algorithm will be and that it will be the exactly the same for both ClassA and ClassB. Why not do the following
Define IMyInterface to inherit from IEquatable<IMyInterface>
Define an abstract base class MyInterfaceBase which implements IMyInterface and has the IEquatable<IMyInterface> implementation
Have ClassA and ClassB derive from MyInterfaceBase

If IEquatable<T> included a GetHashcode() member it might be possible to define meaningful semantics for that type which differed from Object.Equals (e.g. "if one were looking only at the characteristics which are present in T, would the objects be considered the same"). Because it does not, however, there generally isn't much reason to implement IEquatable<T> except in those cases where it can improve performance without adding any quirky semantics. In practice, that means that IEquatable<T> should either be implemented only by T itself (if T is a sealed class or struct), or not at all (if T is inheritable, or if the performance benefits aren't worth the effort).

I would think that if the interface can't be converted to an abstract class, it doesn't make much sense to be comparing the two implemented classes to each other directly or automatically. Meaning that implementing a custom comparison on each class would be the way to go. I'm sure you can refactor the comparison code somehow to make changing it easier later on.