Suggestion: Overloading with generics using where clause

[TheCelticGuy]

Hello

I was wondering if it were possible to overload using generics with a where clause.

An example:

        public static float Area<T>(T points) where T : IList<Vector3>
        {
            float a = 0;
            for (int i = 0; i < points.Count; i++)
            {
                var p1 = points[i];
                var p2 = points[(i + 1) % points.Count];
                a += p1.x * p2.z - p2.x * p1.z;
            }

            return a * 0.5f;
        }

        // member with the same signature already declared
        public static float Area<T>(T points) where T : IList<Vector2>
        {
            float a = 0;
            for (int i = 0; i < points.Count; i++)
            {
                var p1 = points[i];
                var p2 = points[(i + 1) % points.Count];
                a += p1.x * p2.y - p2.x * p1.y;
            }

            return a * 0.5f;
        }

The code considers the two signatures to be the same even though the type is clearly defined in the where clause:

public static float Area<T>(T points) where T : IList<Vector2>
public static float Area<T>(T points) where T : IList<Vector3>

Would it not be possible for C# to detect this as an overload?

[HaloFour]

Generic constraints aren't a part of the method signature in IL, the runtime can't distinguish between them. The runtime would need to be modified to change this, but that would also impact how methods are resolved in IL and require that generic constraints be included in method references. The language couldn't do that much here short of generating mangled names. But that wouldn't work well with other languages in the ecosystem or down-level compilers.

[IS4Code]

The type is not clearly defined. You can have any type implement both IList<Vector2> and IList<Vector3> and then there would be unresolvable ambiguity. Something like where T : class and where T : struct would be a better example.

The methods could actually be differentiated with some modopt on the parameter, and if you create such method in CIL, C# can actually understand it and will correctly call the viable overload.

[NN---]

You can introduce a defaulted parameter with the constraint which solves this in the calling code.
Not as elegant as it could be, but better than nothing.

using System;
using System.IO;

public interface IBinarySerializable {}

public class Read<T> {}

public class RequireBinarySerializableNew<T> 
    where T : IBinarySerializable, new()
{}

public static class C
{
    // Тут для простоты не добавил.
    public static E Read<E>(this BinaryReader reader) where E : struct, System.Enum
    {
        Console.WriteLine("where E : struct, System.Enum");
        return new();
    }

    public static T Read<T>(this BinaryReader r, RequireBinarySerializableNew<T>? _ignore = null)
        where T : IBinarySerializable, new()
    {
        Console.WriteLine("where T : IBinarySerializable");
        return new();
    }
}

class ClassBinarySerializable : IBinarySerializable
{
    public ClassBinarySerializable() {}
}

enum TestEnum {}

class A{
    public static void Main() {
        var a = new BinaryReader(new MemoryStream());
        
        a.Read<TestEnum>();
        a.Read<ClassBinarySerializable>();
    }
}

[siegfriedpammer]

Your motivating example is not very compelling. It does not need generics at all. The method implementations are different and you can simply replace T with the concrete type. Problem solved.

Would be interesting to see an example where this would actually be useful.

[colejohnson66]

Replacing T with the actual IList<Xyz> would necessitate dynamic dispatch. Using a generic would allow static dispatch. Not sure of the performance implications of that in OP's code, but that is one benefit of said generic constraint.

[timcassell]

#2013