Enable deconstructing dynamic objects

[lostmsu]

I imagine it is possible to find matching Deconstruct in the object at runtime either based on target types, or, if target types are unknown as in var (a,b) = default(dynamic), set both to have type dynamic.

[markusschaber]

I think we should first get some experience with the semantics of non-dynamic code in this case, and some compelling use case. It's a complex feature to implement this for dynamic...

[lostmsu]

@markusschaber , do you see any non-trivial edge cases? Anything, that existing binder can not handle?

[alrz]

Deconstruct call generated for a deconstruction uses out var semantics, which can't be used with a dynamic receiver.

[lostmsu]

@alrz I am looking for cases where semantics would be unclear. I understand reusing current implementation is not straightforward.

However, I can see that feature being very useful for Python interop, where if one would want to reuse Python code, that returns a tuple, it should be easy to deconstruct it without figuring out types of components in advance.

var (train, test) = load_dataset();
// or dynamic (train, test) = ...
// or int (train, test) = ... if you know the actual tuple element types
model.fit(train)

[jnm2]

@alrz Could that just be out dynamic?

[lostmsu]

@jnm2, there's no issue on how to define the deconstruction in the class. That part is untouched.

It's only about choosing the right overload at the receiving side based on whether the resulting types are specified or not, and what are they. And then the actual implementation.

[jnm2]

@lostmsu Right; I think that's what @alrz and I are talking about. There is no such thing as out var except at a call site.

[alrz]

@jnm2 Yes, that's exactly what you get with simple local declarations as well. Nevertheless, dynamic is always a special case in every feature, so there should be enough value to support it in each feature. Scratch that, on the second thought, I think this should simply work because (1) dynamic is a part of the language anyways and (2) it's not neither impossible to do nor have unfortunate consequences. Think it's just been tabled for the time being.

@lostmsu I think Joseph is talking about the out argument at the call site that the compiler should generate, not the method declaration.

[alrz]

However, I can see that feature being very useful for Python interop, where if one would want to reuse Python code, that returns a tuple, it should be easy to deconstruct it without figuring out types of components in advance.

I'm not familiar with Python interop, but the resulting dynamic object must provide a Deconstruct method to be called, if you propose that we do this as a simple dynamic invocation.

[lostmsu]

@alrz, it would be up to the interop layer (e.g. Python.NET). They could simply return a ValueTuple or override TryInvokeMember

[YairHalberstadt]

Isn't this extremely straightforward?

Just transform:

dynamic obj = Whatever;
(Type1 a, Type2 b) = obj;

to:

dynamic obj = Whatever;
obj.Deconstruct(out Type1 a, out Type2 b);

?

I suppose two complications arise:

1. Wont work if deconstruct is an extension method. Nothing that can be done about this I guess - it's a general limitation of dynamic.

2. Won't work on valueTuple. Two possible solutions:
   a) dynamically check for valuetuple and special case it:

dynamic obj = Whatever;
if (obj.GetType().Name.Contains("ValueTuple")) // I can't be bothered looking up the correct way to do this right now
   ...
else
{
    obj.Deconstruct(out Type1 a, out Type2 b);
}

b) Just add a Deconstruct method to ValueTuple. You will need to add for every single possible length, so deconstructing a dynamic tuple greater than a certain length wont work. No great loss. You could have a roslyn analyser warn if you try and do that.