Just for this, you ask yourself what kind of var then?

In the case of your example:

var mostra = delegate(string x)
{
    Console.WriteLine(x);
};
mostra("teste");

mostra would be a delegate of what kind? Action<string> ? Or it would be some other kind ... for example, I could invent some kind of delagate:

delegate void Xpto(string str);

And now?

There's no way to tell, because delegates are objects that have a type in .Net.

How to do it then

There are a few ways you can indicate the delegate type to C #:

var mostra = (Action<string>)delegate(string x)
{
    Console.WriteLine(x);
};
mostra("teste");

Or else:

Action<string> mostra = delegate(string x)
{
    Console.WriteLine(x);
};
mostra("teste");

Or else:

var mostra = (Action<string>)(x => Console.WriteLine(x));
mostra("teste");

The latter being an alternative to my first example, only using a lambda to generate the delegate.

Miguel Angelo's answer already answers the question well. I'll just put some information that might help find some other solution in some cases. Of course for the question, the simplest and obvious solution is the second alternative of his answer.

var is not a magic solution and should always be used, it is only a facilitator and when it is not possible to use it just do as it did before it is to use the type explicitly. I do not like cast solutions, although they work. It would only be useful in the case of dynamic since this command "hides" the type at compile time.

Note that this is a problem so difficult to solve that even in runtime it is not possible to unambiguously identify the correct type, so dynamic does not solve either.

Why is it difficult to infer in this case?

Eric Lippert, the creator of this functionality in the compiler, has already explained in his answer in SO because inferring the type of delegate would be very complicated or even impossible.

Variable usage abuse

One thing to think about is whether you need a variable in this case. One thing I realize is very common is that programmers find that variable is something absolutely necessary in a program. And it's not. Variable is just a design pattern .

Of course the code would be unreadable but it is possible to program without using variables. And awesome, respecting the DRY .

I'm not preaching this but as I say exceptions are being abused I say that programmers are abusing variables. Probably because they do not understand that variable is just a place to save a die temporarily. Do not understand that if there is no advantage in storing this data, you should not save it.

Curiously for not understanding this, they make the mistake to the contrary as well. When variables can be used, they end up not using. I speak of this in and this response. People do not understand which expressions can be replaced by variables, so where they know they need an expression, they are forced to create an expression when a variable suffices. I'm tired of seeing this freak:

if (booleanoQualquer == true)

Of course, the variable can be used as a way of documenting the steps that are being done but it is not its main function, it is a side effect.

Conclusion

So it's good to know that the problem really is with var and not with the inference itself. It is possible to infer when there is enough information to infer. If it were not in var but in a place where an expression of a specific type is expected, the compiler can find out if they are compatible. This is well-displayed in this blog . See the code for it .

If you do not have to use a fact variable, do not use it and gain the inference in most cases.

I do not say that you abused because I know it was just a self-contained example.