Discussion: Deconstruction of anonymous types

[geirsagberg]

A useful feature would be deconstruction of anonymous types,. Given the following common pattern for extracting projections from LINQ:

var userNameAndId = MyContext.Users.Select(u => new { u.Id, u.Name }).First();
var userName = userNameAndId.Name;
var userId = userNameAndId.Id;

It would be nice to do the following:

var (userId, userName) = MyContext.Users.Select(u => new { u.Id, u.Name }).First();

The order of the variables would be the same as the order of the declarations in the anonymous type. Alternatively, one could name them if one wanted another order:

var (userName = Name, userId = Id) = MyContext.Users.Select(u => new { u.Id, u.Name }).First();

Of course, one would have to handle cases like .FirstOrDefault(), which might make every deconstructed variable nullable.

[alrz]

With property patterns you could do that,

if ( new { u.Id, u.Name } is { Id: var id, Name: var name } )

However, since this pattern always succeeds, a statement form can help, like dotnet/roslyn#16183

case { Id: var id, Name: var name } = new { u.Id, u.Name };

OR:

_ = new { u.Id, u.Name } is { Id: var id, Name: var name }; 😄 

[HaloFour]

Implementing this feature sounds like it should be relatively simple. The compiler could emit a Deconstruct method in the synthetic anonymous type classes. Since the compiler emits a separate type for each combination of arity and ordered property names this should be safe to do and the deconstruction would "just work" given the other features of the language.

var foo = new { X = 123, Y = 456 };

// synthetic class:
public class AnonymousType0<T1, T2> {
    public T1 X { get; }
    public T2 Y { get; }

    public AnonymousType0(T1 X, T2 Y) {
        this.X = X;
        this.Y = Y;
    }

    // Equals, GetHashCode, etc.

    public void Deconstruct(out T1 X, out T2 Y) {
        X = this.X;
        Y = this.Y;
    }
}

[alrz]

@HaloFour

Type members are unordered, with Deconstruct you are implying an order for anonymous type's properties. Also, the fact that the compiler treats new { X, Y } and new { Y, X } differently just adds more confusion to the feature. Furthermore, in the presence of tuples (that can be deconstructed out of the box), I don't see how that can be useful except that it would just increase IL code size for anonymous types.

[HaloFour]

@alrz

Being simple to implement doesn't imply that it's a good idea. Indeed this relies on an implementation detail of anonymous types that could change in the future.

But I don't see any confusion here, at least not any more confusion than when working with tuples.

While tuples do somewhat obviate the use cases for something like this it doesn't eliminate them. The use case mentioned in this proposal involves Entity Framework, which to my knowledge does not currently support tuples. That may change, but in the meantime the only option to deconstruct the result of a query like that would be:

var (userId, userName) = MyContext.Users
    .Select(u => new { u.Id, u.Name })
    .AsEnumerable()
    .Select(u => (u.Id, u.Name))
    .First();

[dipique]

Doesn't EF generate partial classes? If so, you could just implement a partial class with the Deconstruct method where needed.

[Liero]

@dipique: here are we talking about anonymous type {new { u.Id, u.Name }}. There is no EF class behind this.

[dipique]

@Liero I was saying that, in this case, you could destructure by implementing Deconstruct on the User EF class instead of using an anonymous object + a tuple (with the downside that EF would query every field in the row):

var (userId, userName) = MyContext.Users.First();

You could get around this by also creating a constructor for User that accepts those two values (Id, Name) to create an instance. It wouldn't solve the general problem of deconstructing anonymous types, but it would allow you to use this code:

var (userId, userName) = MyContext.Users
    .Select(u => new User(u.Id, u.Name))
    .First();

[DaveVdE]

That would block the use of projection to reduce the amount of data requested from the database.

[MgSam]

@HaloFour

in the meantime the only option to deconstruct the result of a query like that would be...

I wouldn't say that's the only option. Successive assignment statements (what we've always done) is really not all that horrible or cumbersome here.

I worry there is too much effort being spent trying to cram everything into a single expression, regardless of whether it's worth all that design effort (not to mention its questionable whether readability is actually improved).

[DaveVdE]

Right. Welcome to pattern matching.

[HaloFour]

@MgSam

I wouldn't say that's the only option. Successive assignment statements (what we've always done) is really not all that horrible or cumbersome here.

Sure, there are many things the developer could do. But to invoke "deconstruction" as defined as the specific operation supported by the compiler would require more code than might be necessary. One could always manually reference the properties and assign variables, as is described in the original post.

I worry there is too much effort being spent trying to cram everything into a single expression, regardless of whether it's worth all that design effort (not to mention its questionable whether readability is actually improved).

My point was only that given the current implementation of anonymous types by the C# compiler that this feature could be implemented with very little effort. It's a valid argument that anonymous types aren't positional like tuples are, but given their locality and their syntax I don't think that's much of an issue. It wouldn't be any less readable than tuples.

[Ilia-Kosenkov]

Is there any information on whether a decision was made? If the question is still open, here is a use case that, in fact, brought me here.
Suppose there are two dictionaries, Dictionary<string, T1> d1 and Dictionary<string, T2> d2,
then the folowing can be constructed using LINQ:

var request = d1.Join(d2,
    x => x.Key, 
    y => y.Key, 
    (x, y) => new {x.Key, Left = x.Value, Right = y.Value});

This should produce an IEnumerable<AnonymousType_01<string, T1, T2>>.
AnonymousType_01 is generated, apparently, based on the number of properties and their names:

var x = new {Id = 5, Name = "Name"}; // AnnType_01<int, string>
var y = new {Id = 10, Name = 42}; // AnnType_01<int, int>
var z = new {Id = 10, Names = "Names"}; // AnnType_02<int, string>, difrrernt generic
var xx = new {Name = "Name", Id = 5}; // AnnType_03<string, int>, different generic

Anonymous types respect the names and order of their properties, so can a Deconstruct method, which could be defined like this:

void AnnonymousType_01.Deconstruct(out string key, out T1 left, out T2 right)
    => (key, left, right) = (this.Key, this.Left, this.Right);

following my dictionary join example.
This, in turn, will enable code like this:

foreach(var (_, left, right) in request) 
{
    // Do things
}

This is possible if the join operation is materialized into ValueTuple<string, T1, T2>, which is a value type, compared to an anonymous type, which is a reference one.

[CyrusNajmabadi]

@jcouv Interesting proposal. Given that anonymous types are ordered, it actually does seem like we could make some sort of conversion between them and tuples :)

[CyrusNajmabadi]

Suppose there are two dictionaries, Dictionary<string, T1> d1 and Dictionary<string, T2> d2,
then the folowing can be constructed using LINQ:

Sure... you could do this, but why not just write:

var request = d1.Join(d2,
    x => x.Key, 
    y => y.Key, 
    (x, y) => (x.Key, Left: x.Value, Right: y.Value);

The anonymous type just seems like unnecessary intermediary steps (not to mention allocations).

[DaveVdE]

You can't use tuples in an expression.

[DavidArno]

@DaveVdE,

You can't use tuples in an expression.

The compiler disagrees with you

[pinkfloydx33]

Those are Func<,>, not Expression<Func<,>> which is what I believe was meant by "expressions". The latter disallows tuple syntax. However ValueTuple.Create is supported, though the query provider would have to recognize it

[Ilia-Kosenkov]

@CyrusNajmabadi, I agree that tuples are much easier to deal with, but anonymous types were there long before ValueTuple was introduced, and anonymous types could still be used in conjunction with LINQ (old habit, perhaps). I could imagine a situation when an anonymous type is fed to some reflection-based library to do some mapping/conversions. In that case, it can be passed as object and inspected with .GetType().GetProperties(), which will allow matching properties by type and name. This will not work for ValueTuple, as tuple names are stored as an attribute and cannot be retrieved via reflection.

Assuming that anonymous types can still be used somewhere, it could be nice to have a Deconstruct method to make developer's life easier. One extra thing would be pattern matching, which is partially built atop deconstruction, so something like anonymousVar is ("key", {} left, {} right) or anonymousVar switch { ("key", {}, {}) => true, _ => false} would be possible.
However, pattern matching can be achieved already using property matching, as suggested above, so anonymousVar switch { {Key: "key", Left: {}, Right:{}} => true, _ => false} should work as well.

I am not saying that this should be implemented because it requires an introduction of a new instance method on all generated anonymous types, I was just surprised to find this discussion still open and with no decision made.

[DaveVdE]

I meant to say expression trees: dotnet/roslyn#16995

…

On Mon, Mar 13, 2023 at 9:40 AM David Arno ***@***.***> wrote: @DaveVdE <https://github.com/DaveVdE>, You can't use tuples in an expression. The compiler disagrees with you <https://sharplab.io/#v2:EYLgtghglgdgNAFxAJwK7wCYgNQB8ACATAIwCwAUPgAwAE+xAdADKwCOA3BdXcQCyfkKANwjIaGYjQC8NGAFMA7jQAiUAMYIoAexiiAngB56VODVgIAfBQDeFGvZoBtAEQRnAXWk1icOw5fAHl6EFAC+AsKi4oRe8kqqGtq6yIbGpuYWABQAlDQ2fvYBQTLEJgVOzmrFNIRUYRHkImLIcqyocgDOCF4SDABSWrCZGIS+5A40AB7SFlMMANJyeqblejM0egtLK+MOmZOmerlSs/tbyzRMcgBmSHMAahAANu2mAEpQAOYAFnebjy85Nlsg1rloWhA1N9Mk0zAg5GAzDAaC02p0ENl8rt7PQAJyZAAkzmsUHhYHOoVMJLJzBuCEpNGpCIYHx+9OcILCQA==> — Reply to this email directly, view it on GitHub <#244 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE64CCCGZ753EQ53DYOQDTW33MQ7ANCNFSM5DYJHCDA> . You are receiving this because you were mentioned.Message ID: ***@***.***>