Namespace scoped aliases for generic types in C#

Let's have a following example:

public class X { }
public class Y { }
public class Z { }

public delegate IDictionary<Y, IList<Z>> Bar(IList<X> x, int i);

public interface IFoo
{
    // ...
    Bar Bar { get; }
}

public class Foo : IFoo
{
    // ...
    public Bar Bar
    {
        get
        {
            return null; //...
        }
    }
}

void Main()
{
    IFoo foo; //= ...
    IEnumerable<IList<X>> source; //= ...
    var results = source.Select(foo.Bar); // <- compile error here
}

The compiler says:

The type arguments for method 'System.Linq.En开发者_运维百科umerable.Select(System.Collections.Generic.IEnumerable, System.Func)' cannot be inferred from the usage. Try specifying the type arguments explicitly.

It's because, it cannot convert Bar to Func<IList<X>, int, IDictionary<Y, IList<Z>>>.

It would be great if I could create type namespace scoped type aliases for generic types in C#. Then I would define Bar not as a delegate, but rather I would define it as an namespace scoped alias for Func<IList<X>, int, IDictionary<Y, IList<Z>>>.

public alias Bar = Func<IList<X>, int, IDictionary<Y, IList<Z>>>;

I could then also define namespace scoped alias for e.g. IDictionary<Y, IList<Z>>.

And if used appropriately:), it will make the code more readable. Now, I have to inline the generic types and the real code is not well readable:(

Have you find the same trouble:)? Is there any good reason why it is not in C# 3.0? Or there is no good reason, it's just matter of money and/or time?

EDIT: I know that I can use using, but it is not namespace scoped - not so convenient for my case.

EDIT2: See comment by Joren where he suggests that structural typing might also solve the problem.

You're out of luck; the using directive affects only its current file. There is no namespace-wide type aliasing mechanism.

This is a fairly frequently requested feature, which is points for it. But it is also a "nice to have" convenience feature as opposed to one that really adds lots of representational power to the language, which is points against it. It would be nice to do, but it's not really high on the priority list.

If you do ...

var results = source.Select((x, i) => foo.Bar(x, i));

it can figure out the types for you without having to specify them explicitly.

(Admittedly this is more of a work-around than a solution)