Is there anything planned for implicit conversion of generics?

[rikimaru0345]

Hello,
maybe a issue for that already exists, but I'm not sure what to search for (I tried a few things but they came up with nothing so my apologies for that).

So my problem is as follows, I'm writing a library that is similar to linq-expression trees.

My problem lies in the following code, and I wonder if there could be anything done to make it so I can express this more easily. It does work, but it's not elegant at all.

Similar to linq-expressions I also have a "inline" syntax to generate a code tree (as if you'd do using Static System.Linq.Expressions;), and that's what I'm using here:

var disposeCall = CallInst(Cast<IEnumerator<TItem>, IDisposable>(enumeratorExp), "Dispose");

The need for a Cast is what is bothering me here, a IEnumerator<TItem> should be directly assignable to a IDisposable because the enumerator type implements IDisposable.

Just in case this already IS possible and I'm just doing something massively wrong, here is the relevant code:

public static CastExpression<TSource, TTarget> Cast<TSource, TTarget>(Expression<TSource> expression)
		{
			return new CastExpression<TSource, TTarget> { Expression = expression };
		}

class CastExpression<TSource, TTarget> : Expression<TTarget>
	{
		public Expression<TSource> Expression;

		Func<TSource, TTarget> _converter;

		public override void Initialize()
		{
			Expression.Initialize();

			// Casters<...> is a static class that caches the casting Func<> that I generate using Linq-Expressions and then compile to a Lambda.
			_converter = Casters<TSource, TTarget>.Operator;
		}

		public override TTarget Evaluate(ScriptStackFrame frame)
		{
			var val = Expression.Evaluate(frame);
			return _converter(val);
		}
	}

Could this be improved somehow? Maybe relaxing the rules of how generics are assignable exactly?
Are there any suggestions going into that direction open already?

I found one issue on here that is about being able to omit a part of the generic type definition when the compiler can infer it, but I don't think that's really relevant here, or is it?
#1349

edit:

I realized that the core of the problem can be shown in a simplified way:

class Expression<T> { }

static void CallInst<TObject>(Expression<TObject> obj) 
{
}

This doesn't work:

Expression<IEnumerator<int>> e = null;
CallInst<IDisposable>(e);

IEnumerator<int> implements IDisposable, so why can't it be converted?

[svick]

IEnumerator<int> implements IDisposable, so why can't it be converted?

The feature you're looking for is called covariance. C# does support covariance in interfaces (and delegates), but it has to be explicitly declared by using the out keyword on the type parameter. That means your code will compile if you change Expression to:

interface Expression<out T> { }

As for why covariance is so limited and doesn't happen automatically, consider this code:

static void AddToList<TObject>(List<TObject> list, TObject value)
{
    list.Add(value);
}

List<IEnumerator<int>> e = null;
CallInst<IDisposable>(e, new MemoryStream());

This code is clearly wrong, since it attempts to add MemoryStream (which implements IDisposable, but not IEnumerator<int>) into a list of IEnumerator<int>. But if your example code was to compile, presumably this code would compile too.

[rikimaru0345]

I see, that makes sense.
For some reason I thought the in/out keywords were similar to the __makeref and the likes and not available directly, just used internally by the CLR.

Good to know, thank you for clearing that up!

[jnm2]

@rikimaru0345 __makeref is available directly. The IDE experience is just "broken" since the keyword is treated as undocumented.