match with anonymous/dynamic types

[marioilitio]

consider the following example:

switch (myobject) {
    case dynamic (string Name, object Value) mycolumn:
    {
         string name = mycolumn.Name;
    }
    break;
}

in this case myobject (of any unknown type) can be matched with any type that have "some" structure in their properties.

[YairHalberstadt]

Can you please give a description of this issue?

What is the problem you're trying to solve, with examples?
what is your proposed solution?
What is the syntax and semantics of your proposed solution, with examples?

[marioilitio]

done, sorry

[YairHalberstadt]

No problem, thanks.

[HaloFour]

C# 8.0 should bring recursive matching of anonymous types as you're allowed to omit the type name when it's known by the compiler, but that would only work if the compiler knows that the variable is of the anonymous type and not a generic type or object.

I want to say that the team has mentioned pattern matching on dynamic as something to consider but I can't find it in any of the notes. From what I recall the binding API behind dynamic doesn't really offer a way to test if a type supports the members, if it fails to bind then it throws.

[YairHalberstadt]

I can definitely see the benefit of matching on some form of structural/duck typing. It would also be compile time verifiable, unlike using dynamic directly.

However I wonder if there's anyway to generate the switch more efficiently than just using dynamic. I can't think of any.

In general the lack of structural typing is actually a big issue in C# IMO. Nominative typing has its advantages, and is easier to implement without a dynamic runtime, but typescript has shown the power of structural typing when running on a dynamic runtime. It would be nice if there was a more general solution to this IMO

[HaloFour]

@YairHalberstadt

I can definitely see the benefit of matching on some form of structural/duck typing. It would also be compile time verifiable, unlike using dynamic directly.

I expect that to come up as shapes/typeclasses get more attention. I can see it being somewhat tricky, though, as you'd have to be matching against the witness.

[YairHalberstadt]

@HaloFour
I really don't see how that would work.
What code would you generate to match against a witness?

[marioilitio]

Even when DLR support would be nice there is another (compile time) approach for anonymous:

var array = new object[] { 2019, "January", new { WeekName: "Monday", IsHoliday: false }};
foreach (var item in array)
    switch (item) {
        case int year: … break;
        case string month: … break;
        case class (string WeekName, bool IsHoliday) anonymous: … break;
    }

(see the use of class instead of dynamic in this cases)
This can be resolved in compile time as any other inference for anonymous typed expressions.
Also, you could consider the "anonymous" construction:

class ([<property declarations>])

as a way to refer to anonymous types

[YairHalberstadt]

@marioilitio
That would also require dynamic calls, since two anonymous types with identical properties are not guaranteed to share the same type.

[HaloFour]

@YairHalberstadt

What code would you generate to match against a witness?

At this point I have no idea, especially as some of the latest discussion around "roles" and "extension interfaces" seem to differ quite a bit from the discussions around "shapes" and "typeclasses". The newer discussion doesn't seem to dig a lot into the implementation details, so I'll base this example on shapes:

public shape PersonLike {
    string FirstName { get; }
    string LastName { get; }
}

public class Person {
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

class C {
    static void M(Person person) {
        if (person is PersonLike { FirstName: "Tim", LastName: var lastName }) {
            Console.WriteLine($"Hello Mr. {lastName}!");
        }
    }
}

The compiler would generate the witness struct as follows:

public struct Person_PersonLike : PersonLike<Person> {
    public static string get_FirstName(Person @this) => @this.FirstName;
    public static string get_LastName(Person @this) => @this.LastName;
}

And the compiler would emit something like the following for the match itself:

Person_PersonLike witness = default;
if (person != null) {
    string firstName = witness.get_FirstName(person);
    if (firstName == "Tim") {
        string lastName = witness.get_LastName(person);
        Console.WriteLine($"Hello {lastName}!");
    }
}

[YairHalberstadt]

But that's all a case where we know the type, and hence the type of the witness.

How would you match object against a shape?

[HaloFour]

@YairHalberstadt

How would you match object against a shape?

You don't. As is the case here the only ways to do that are via reflection or dynamic binding, both very slow and error prone.

[YairHalberstadt]

That's my point.

[HaloFour]

@YairHalberstadt

You mentioned that it would be "compile time verifiable" which would require that the compiler know about the type during compilation at which point it can emit the witness and plumb the match against that. Against object there'd be no way to make that "compile time verifiable".

[YairHalberstadt]

It would all be a compile time trick, but you can generate reflection code which looks for a suitable witness and tries to match against that.

[marioilitio]

Is it so problematic to compiler, to match itself whether two anonymous types are structurally compatible in terms of a match?

[YairHalberstadt]

It's not a problem with the compiler. It's a problem with the runtime and the type system.

[YairHalberstadt]

Problem in the looser sense of the word. I.e. that's just not how the type system works. There's alternative type systems, but they have their own issues.

[HaloFour]

@YairHalberstadt

It would all be a compile time trick, but you can generate reflection code which looks for a suitable witness and tries to match against that.

How would the compiler look for a suitable witness if it doesn't know the type? It'd have to emit code at runtime to literally look at all possible implementations of the "shape" interface.

@marioilitio

Is it so problematic to compiler, to match itself whether two anonymous types are structurally compatible in terms of a match?

The compiler has to know that it's an anonymous type to begin with. Once you've assigned that anonymous type to an object that information is effectively lost. Without knowing the actual type there's really nothing that the compiler can match against without using reflection or dynamic.

[YairHalberstadt]

@HaloFour
Essentially yes. It could be made more efficient by caching a dictionary of types to witnesses.
It also would leave wide open the question of when a witness is in scope, seeing as using directives are lost at runtime.

[HaloFour]

@YairHalberstadt

So, not "compile time checked" then. IMO that's not a reasonable way to negotiate types for a match. Dynamic binding would probably be more efficient.

[marioilitio]

@YairHalberstadt

It would all be a compile time trick, but you can generate reflection code which looks for a suitable witness and tries to match against that.

How would the compiler look for a suitable witness if it doesn't know the type? It'd have to emit code at runtime to literally look at all possible implementations of the "shape" interface.
@marioilitio

Is it so problematic to compiler, to match itself whether two anonymous types are structurally compatible in terms of a match?

The compiler has to know that it's an anonymous type to begin with. Once you've assigned that anonymous type to an object that information is effectively lost. Without knowing the actual type there's really nothing that the compiler can match against without using reflection or dynamic.

As I can see, this anonymous object can live as the same citizen class as the others (int, string, etc.) on the last example I post before. If the compiler can match/infer a named type, I thing it could do the same for anonymous, which are, in the end, also named types (compile-time named types)

[HaloFour]

@marioilitio

If the compiler can match/infer a named type

The compiler can only match with such an inference when the type is known at compile time. Once you've cast to object you lose that information and the compiler can't make any such inference.

[marioilitio]

As I can see, this anonymous object can live as the same citizen class as the others (int, string, etc.) on the last example I post before. If the compiler can match/infer a named type, I thing it could do the same for anonymous, which are, in the end, also named types (compile-time named types)

[YairHalberstadt]

It can't, because it doesn't know the name of the anonymous type. Their could be infinite anonymous types with the same signature. How does it know which is the correct one to use?

[marioilitio]

how is it done with delagates? there are also a lot of delegates with the same signatures, even though lambda expressions can be matched in compile time... is it not a similar compiling approach?

[YairHalberstadt]

how is it done with delagates? there are also a lot of delegates with the same signatures, even though lambda expressions can be matched in compile time... is it not a similar compiling approach?

delegates cannot be matched:

class Program
{
    delegate int A(int a);
    delegate int B(int a);
    static int M1(int a) => 42;
    static void M()
    {
        B b = M1;
        if (b is A a) Console.WriteLine("true"); //Will not compile
        if ((object)b is A a) Console.WriteLine("true"); else Console.WriteLine(false); //prints false 
    }
}

When you create a lambda it is target typed, meaning the compiler will look how it is used to decide which type to create, but that has nothing to do with this scenario.

[git-net]

useful.
now,i use expreeesion

var a=o.Seems(c=>new {Id=1,GetName=default(Func<string>)....});//o is object,
if(a!=null) b.UID=a.Id;
.....

works but slow