Namespace scoped aliases for generic types in C#

Question

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.Enumerable.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.

Titanothere

I'm not sure what the problem with using is -- granted it doesn't define a new type, but isn't that what you want? – Perfection

As I wrote, it is not namespace scoped, but rather file scoped. I need to use the alias across cs files and assemblies. – Titanothere

Answer 1

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.

Springhalt

If I'm not mistaken, structural typing on delegates might also allow the compiler to deal with this specific situation, albeit in a very different way. Is there any reasonable chance that support for structural typing for things like delegates will sometime be implemented? – Overburden

@Joren: Yes, that would solve this problem. I think most people now realize that it might have been better to have structural typing on delegates from the beginning, but that ship has sailed. It would be a pretty big breaking change to change it now. That said, there is renewed interest in structural typing, so I wouldn't want to make the statement that there is no chance of this happening. – Springhalt

Answer 2

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)

Bolster