Constraint type inference

[rick-de-water]

This is something that has been on many people's wish lists for a while, but now with the addition of generic math it has gained a new use case.

Lets say I want to define a generic 3d vector interface:

public interface IVector3<T>
{
    T X { get; set; }
    T Y { get; set; }
    T Z { get; set; }
}

As well as a float implementation for this example:

public struct Vector3f : IVector3<float>
{
    public float X { get; set; }
    public float Y { get; set; }
    public float Z { get; set; }
}

I then want to define a cross product method that works for any vector, as long as the numeric constraints are met:

public static class Vector
{
    public static TVector Cross<TVector, TElement>(TVector v1, TVector v2)
        where TVector : IVector3<TElement>, new()
        where TElement :
            System.Numerics.ISubtractionOperators<TElement, TElement, TElement>,
            System.Numerics.IMultiplyOperators<TElement, TElement, TElement>
    {
        var result = new TVector();
        result.X = v1.Y * v2.Z - v1.Z * v2.Y;
        result.Y = v1.Z * v2.X - v1.X * v2.Z;
        result.Z = v1.X * v2.Y - v1.Y * v2.X;
        return result;
    }
}

Perfect! Lets try it out:

var v1 = new Vector3f();
var v2 = new Vector3f();
var v3 = Vector.Cross(v1, v2);

So close:

error CS0411: The type arguments for method 'Vector.Cross<TVector, TElement>(TVector, TVector)' cannot be inferred from the usage. Try specifying the type arguments explicitly.

So instead you have to write the following:

var v1 = new Vector3f();
var v2 = new Vector3f();
var v3 = Vector.Cross<Vector3f, float>(v1, v2);

Which is not something we want to type all the time. We want C# to infer the types for us.

An alternative would be to change the method signature to Cross(IVector3<TElement> v1, IVector3<TElement> v2). This however would lead to boxing, which has significant performance implications.

So I suggest the language team to reconsider constaint type inference. Right now generic math is unable to reach its full potential without it. Vectors and Matrices, Complex numbers and Quaternions, Points, Sizes and Rectangles, these are all multi value math structures that can greatly benefit from this feature.

[Joe4evr]

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

And here's a comment describing why it's problematic to do.

[davidroth]

@333fred What about just fallbacking and not introducing a flag?

So for this case:

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

M("foo")

determine if there are overloads for M with ambiguous constraints

1. if no: assign the type arguments based on input
2. if yes: use the M(object) overload

No flag, it would only work for new apis where there is no overload with (object)

[agocke]

determine if there are overloads for M with ambiguous constraints

There's no ambiguity in the original examples. object is better because T fails type inference. Resolution succeeds against object with no other alternatives.

[333fred]

But there's nothing saying we can't add a feature to let users change overload resolution for their own overloads. That's basically the idea behind the proposed OverloadResolutionPriority attribute.

The key difference to me is that OverloadResolutionPriority is a "hopefully you never need it" attribute, whereas this would be a "why aren't you putting this on all your methods" attribute. Probably more nuisance than useful overall.

[agocke]

So the problem with ImprovedInferenceAttribute is that it's too good and the other methods might get jealous? 😉

Just saying, we could also allow targeting the assembly...

[thomhurst]

Suggestion here for an implicit keyword:
dotnet/roslyn#7850 (comment)

[thomhurst]

I'm building a library with some complicated constraints. Due to this lack of automatic inference, some of the things I want to do have become undo-able because I can't expect the caller to have to put in my complicated generic arguments. See #8205