Improve generic type parameters inference.

[MkazemAkhgary]

When a generic type parameter is constrained with other generic parameters, it is possible to infer both types from constrained generic type. (currently not supported by compiler)

public static Foo<TBar, T> AsFoo(this TBar bar) where TBar : IBar<T>
{
     return new Foo<TBar, T>(bar);
}

when calling this.

var foo = bar.AsFoo(); // type parameters can not be inferred.

but It should be inferred, because information about T already exist in constraint for TBar here where TBar : IBar<T>

[khellang]

Related/duplicates: #110, #478, #741, dotnet/roslyn#5023 and dotnet/roslyn#15166.

There's even PRs where this work was already done: dotnet/roslyn#6644 and dotnet/roslyn#7850.

[bbarry]

This unfortunate observation describes the problem with doing this:

Suppose you have these methods:

public static Foo<string, char> AsFoo(this object bar) =>
    new Foo<string, char>(bar);
public static Foo<TBar, T> AsFoo(this TBar bar) where TBar : IEnumerable<T> =>
    new Foo<TBar, T>(bar);

this call would change:

var foo = bar.AsFoo(); 

[benaadams]

And if it didn't I'm not sure you could implement ValueLinq without creating all new List<T> etc classes

As

public static int Count<TSource>(this IEnumerable<TSource> source)

Would take precedence over

public static int Count<TEnumerable, TEnumerator, TSource>(this TEnumerable source)
    where TEnumerable : struct, IValueEnumerable<TSource, TEnumerator>
    where TEnumerator : struct, IValueEnumerator<TSource>

for

var c = collection.Count();

(Ideally I'd like the struct constraint to give a boost in matching; if not the fact it remains generic rather than an interface; all the way - so no casting or loss of type information happens)

(Though could sorta work by switching usings)

[gafter]

@agocke is investigating extending type inference to take constraints into account.

[benaadams]

From: #982 (comment)

The main issue is lack of inference of generic arguments based on constraints so you need to do:

list.Any<List<int>, List<int>.ValueEnumerator>();
list.Count<List<int>, List<int>.ValueEnumerator>();

Rather than

list.Any();
list.Count();

To resolve

public static int Count<TSource, TValueEnumerator>(this TSource source)
    where TSource : IValueEnumerable<TValueEnumerator>
    where TValueEnumerator : struct, IValueEnumerator

However, running a perf test for a "ValueLinq" https://gist.github.com/benaadams/294cbd41ec1179638cb4b5495a15accf

    Method | Categories |      Mean |     Error |    StdDev | Scaled | Allocated |
---------- |----------- |----------:|----------:|----------:|-------:|----------:|
      Linq |        Any | 16.718 ns | 0.0615 ns | 0.0480 ns |   1.00 |      32 B |
 ValueLinq |        Any |  8.241 ns | 0.0286 ns | 0.0253 ns |   0.49 |       0 B |
           |            |           |           |           |        |           |
      Linq |      Count | 69.538 ns | 0.3562 ns | 0.2781 ns |   1.00 |      32 B |
 ValueLinq |      Count | 35.665 ns | 0.1095 ns | 0.0970 ns |   0.51 |       0 B |

Its twice as fast and cuts allocations to zero

[agocke]

My summary here: the break is real, but much of the annoyance is around inference failure -- when there are no other suitable overloads, but the compiler still fails to properly infer your generic arguments.

I think the only way to deal with that is re-do overload resolution after an inference failure, this time taking constraints into account. This could be expensive, so we would have to decide whether that's something we want to do, or whether we can accept some overload resolution breaking changes.

[MkazemAkhgary]

@agocke what about having a compiler option, if not activated everything is normal.

but when activated, it should disallow overloads like this

void M(object) {}
void M<T, U>(T t) where T : IEnumerable<U> {}

and improve generic type inference to the maximum.

I mean, this kind of overload is really trash. I don't think one would ever make overload like this or at least won't do it on a regular basis.

but when they do, they shouldn't be able to compile with the new option. and new projects by default should have this option enabled by default, because why not :)

[Joe4evr]

Code depending on compiler options creates a dialect, and the Language Design Team has been hard at work for the past 15+ years to keep dialects as far away from the language as possible.

[Ultrahead]

dotnet/roslyn#7850 (comment)

[QXD-me]

@agocke I know it’s been a while on this issue. But does expensive in this case mean in terms of compilation time or expense of dev time to implement?
If it is compilation time that’s at stake isn’t code usually “mostly working” I.e. only the bit you’re working on is broken, so there shouldn’t be that many methods that need rechecking? I guess maybe if someone renames a method without using the refactor tool there might be more?
And presumably you would only need to recheck against types that have constraints, rather than rechecking all possibilities?
(I’m not familiar with the compiler internals, so please forgive my ignorance if what I’m saying is dumb)

[CameronAavik]

I have a workaround that I have been using for this problem, but it still gets a bit messy so having this inference working in the compiler would be preferable. The workaround is to place the generic type inside a wrapper struct and ensure all the types that are not being inferred are present in the generic types of that struct. For example assume here is a minimal repro of the issue from the OP:

var bar = new Bar<int>().AsFoo(); // error CS0411

public interface IBar<T> {}
public record Bar<T>() : IBar<T>;
public record Foo<TBar, T>(TBar Bar) where TBar : IBar<T>;

public static class IBarExtensions
{   
    public static Foo<TBar, T> AsFoo<TBar, T>(this TBar bar) where TBar : IBar<T>
        => new Foo<TBar, T>(bar);    
}

To fix it, you create a BarWrapper type and then define the extension method off the wrapper type.

var bar = new Bar<int>().Wrap().AsFoo(); // works without error

public interface IBar<T> {}
public record Bar<T>() : IBar<T>
{
    public BarWrapper<Bar<T>, T> Wrap() => new(this);
}

public record BarWrapper<TBar, T>(TBar Bar) where TBar : IBar<T>;
public record Foo<TBar, T>(TBar Bar) where TBar : IBar<T>;

public static class IBarExtensions
{   
    public static Foo<TBar, T> AsFoo<TBar, T>(this BarWrapper<TBar, T> wrapper) where TBar : IBar<T>
        => new Foo<TBar, T>(wrapper.Bar);    
}

Obviously there is a bit of pain in that you need to constantly wrap the objects to use it, but if you were making a library such as StructLinq, then what you can do is always deal with your objects inside this wrapper. So if you were to define a Select method, rather than defining an extension method directly on the stream type and returning the stream type, you would define an extension method on the wrapper and then it returns the stream inside the wrapper.

An example of using this approach for a StructLinq style library is as follows:

using System;

static StreamWrapper<ArrayStream<T>, T> CreateStream<T>(T[] array) => new(new(array));

var arrayStream = CreateStream(new int[] { 1, 2, 3 });
var addOneAndDouble = arrayStream.Select(x => x + 1).Select(x => x * 2); // no errors!

public interface IStream<T> {}
public record struct ArrayStream<T>(T[] Array) : IStream<T>;
public record struct SelectStream<TStream, T, TResult>(TStream BaseStream, Func<T, TResult> Selector) : IStream<TResult>
    where TStream : IStream<T>;
public record struct StreamWrapper<TStream, T>(TStream Stream) where TStream : IStream<T>;

public static class IStreamExtensions
{   
    public static StreamWrapper<SelectStream<TStream, T, TResult>, TResult> Select<TStream, T, TResult>(
        this StreamWrapper<TStream, T> streamWrapper,
        Func<T, TResult> selector)
        where TStream : IStream<T>
        => new(new(streamWrapper.Stream, selector));    
}

[TLabWest]

I know this issue is duplicated all over the place and I'm not sure where to continue the discussion, please point me to the relevant issue if there is a better one.

If I have understood the main problem correctly, LDM commented on breaking changes as described in dotnet/roslyn#7850 (comment)

I just wonder if we could add something like a new infer keyword to make the functionality optional? So from:

void M<T, U>(T t) where T : IEnumerable<U> {} // No changes in current behaviour

to:

void M<T, U>(T t) infer where T : IEnumerable<U> {} // Use constraint to infer types

Or is adding new keywords completely out of the question? What about characters, like a bang or similar added to the constraint?

void M<T, U>(T t) where T! : IEnumerable<U> {} // Use constraint to infer types

This issue keeps coming up when we're making our API:s, forcing us to make ugly compromises between usability and type safety.

[HaloFour]

@TLabWest

I don't believe that the issue is related to syntax. The exploration seems to indicate that it was possible, but that the failure modes left something to be desired. There are other proposals around partial inference and associated types that the team has also been looking into.

[TLabWest]

@HaloFour Unless I am mistaken the original idea was declined after LDM found it would cause a breaking change in the behavior of overloaded methods, please see dotnet/roslyn#7850 (comment) for an example.
My suggestion is to add some minor syntactic sugar to make the new behavior optional. Others have suggested compiler options, which I don't think is a great idea.

[HaloFour]

It also states that being a breaking change doesn't disqualify it from being considered.

It's more likely that the team wants to address something like this with associated types as that covers the same use cases: #1328

[TLabWest]

Thanks for link. Just skimming through that discussion I can't immediately see how that would cover this use case but I'm pretty sure I've missed some important factor. I'm just eager to finally get this issue addressed.

[HaloFour]

I thought they did call out the IEnumerable<T> scenario in that proposal but I guess not. I believe it's covered by that approach, though, as the associated type would be the generic type parameter that only really serves to support another generic type parameter.

[miyu]

Seconding TLabWest's point, explicitly opting-in to implicit type inference would avoid introducing a breaking change.

In summary (I was about to start a separate discussion before I saw this thread)

It'd be nice to infer generic arguments from constraints:

void M<T, TCollection>(TCollection t) where TCollection : IEnumerable<T> {}
M(new List<int>());  // M<int, List<int>>; currently errors.

That currently fails with:

Error: The type arguments for method 'M<T, TCollection>(TCollection)' cannot be inferred from the usage. Try specifying the type arguments explicitly.

dotnet/roslyn#7850 implements inference. It is rejected as a breaking change:

void M(object t) {}
void M<T, TCollection>(TCollection t) where TCollection : IEnumerable<T> {}
M("Test") // currently invokes M(object) but with the change would invoke M<char, string>

As a workaround, we could gate this functionality behind an opt-in:

void M1(object t) {}
void M1<T, TCollection>(TCollection t) where TCollection : IEnumerable<T> {}
M1("Test") // Invokes M1(object)

void M2(object t) {}
void M2<implicit T, TCollection>(TCollection t) where TCollection : IEnumerable<T> {} // Note the M2<implicit T
M2("Test") // Invokes M2<char, string>

[miyu]

I like implicit as an already-reserved keyword (with explicit being the implicit default :P). It's already used for operator-keyword implicit casting and has a similar behavior. No need to introduce a new keyword, no need to worry about a class already being named "infer".

[miyu]

Also, as an alternative to IValueEnumerator/IValueEnumerable approach, I've been implementing my StructLinq over enumerators, not enumerables (though I've made my enumerators enumerable, returning themselves):

var numbers = Enumerable.Range(0, 1000).ToList();
var typeHint = numbers.HintElementType(); // int
foreach (var n in numbers.GetEnumerator().Where(typeHint, static i => (i % 2) == 0).Map(typeHint, i => i * 1000)) 

Which lowers to:

StructLinq.Map(StructLinq.Where(numbers.GetEnumerator(), typeHint, static i => (i % 2) == 0), typeHint, i => i * 1000)

And has the type StructLinqMap<int, StructLinqWhere<int, List<int>.Enumerator>, int>. With inference here, we could drop the type-hinting variable.

One should also look at https://github.com/reegeek/StructLinq (MIT license) which has sidestepped this issue with code like:

list
   .ToStructEnumerable()
   .Where(x => (x & 1) == 0, x=>x)
   .Select(x => x * 2, x=>x)
   .Sum(x=>x);

Presumably they're writing ToStructEnumerable() extension methods per BCL collection, e.g.;

public static class Extensions {
   public StructEnumerable<T, List<T>.Enumerator> ToStructEnumerable<T>(this List<T> x) => new(x.GetEnumerator());
}

[miyu]

I've pasted my StructLinq code here under public domain for anyone interested: https://gist.github.com/miyu/225b9ecf46111cdd9591cf3c7b517587