Property pattern matching in where clause for generics

[klirium]

It's more like TypeScript's shape model, but Is it too much doing this?

internal class Point
{
    public int X { get; set; }
    public int Y { get; set; }
}


public static void Main()
{
    var o = new Point() { X = 4, Y = 5 };
    Gen(o);
}

// What if we does not have access to Point class and cannot implement IPoint interface on it. 
// Can we check a shape of a type when passing it to a generic function?
public static void Gen<T>(T point) where T : is { X: int, Y: int} 
{
    Console.WriteLine(point.X);
}

[KennethHoff]

This sounds like it could be solved via #5497, by defining your own interface and implementing that interface on behalf of whatever you want

[colejohnson66]

Shapes are a neat concept, but basically mandate the use of runtime lookup, which destroys performance. There's no guarantee that X in one object has the same field offset as X in a different type. TypeScript (well, JavaScript) bypasses this limitation because every property access is just indexing into a dictionary.

I'm curious to see how extensions solve the field offset issue.

[HaloFour]

Shapes are a neat concept, but basically mandate the use of runtime lookup, which destroys performance.

I believe the goal is that extension implementation would be a zero-cost abstraction. I don't know where the thinking is with the implementation these days, but earlier on it was through struct "witness" types, so the runtime would be capable of specializing the implementation and inlining the invocation of the member on the target type.

[wherewhere]

Things like this maybe need reflection, just like new() actually is System.Activator.CreateInstance<T>().

public static string Test<T>(T value) where T : { string Test(); }
{
    return value.Test();
}

【.NET】利用 IL 魔法实现随心随意的泛型约束