Proposal: Wildcard '*' for building anonymous types (like "select *" in SQL)

[springy76]

Example:

var anon = new { x.*, y.* };

The compiler would only have to flatten this out to

• all public properties with getters
• (named) members of value tuples

in an early phase of compilation (which will fail if this introduced name conflicts).

Main usage would be for building complex LINQ queries which finally are displayed in a data grid so I want as many direct properties as possible instead of just nested object references.

[svick]

I'm not convinced this would actually work that well. Even with your given use case of flattening properties to be displayed in a data grid, I can imagine several situations where the proposed feature wouldn't work well:

• Both x and y have properties with the same name (like Id or Name).
• You want to hide one of the properties.
• You want to decide the order in which properties will be displayed.
• You want to use custom names for some properties.

Because of that and because your use case is fairly limited and I don't see many other use cases where such feature would be useful, I don't think it makes sense to include this feature in the language.

Does the data grid control you use not have some form of customization that you could use instead of this feature?

[springy76]

For me this is a every day issue way back to 2006 or so when LINQ appeared the first time, and on first day one of the first questions was "where is select *"?

The "data grid control" is actually LINQPad, both datagrid and HTML table view. There are days where I spend hours in prototyping queries or just studying data with all sorts of group-by etc.
In production code this is rare but occurs, too (but not "grid" related).

What happens nearly every time is that I need a transition from IQueryable to IEnumerable to add additional columns which EF+SQL just cannot calculate:

from x in query.AsEnumerable()
select new {x.p1, x.p2, x.p3, x.p4, x.p5, x.p6, x.p7 [......], Bitmask = Convert.ToString(x.p27, 2)}

could be so nice:

from x in query.AsEnumerable()
select new {x.*, Bitmask = Convert.ToString(x.p27, 2)}

Similar thing with groupings because ALL THE TIME I'm forgetting to update the final select list when I modify the group key:

from x in enumerable
group x by (x.p1, x.p2, x.p3) into g
select new { g.Key.*, Count = g.Count(), Samples = g.Take(3) }

[HaloFour]

Sounds like something that should be handled in LINQPad, not C#. There are too many caveats to make this worthwhile for those rare times that it might actually be useful in production.

[springy76]

I don't think that LINQPad should mess with or even change C# code. And I don't see any caveat because nothing hinders you to skip that language feature and do it by hand as before. Personally the cases where I would have used more then one "*" might be zero.

I guess someone who knows how to code Roslyn features would do that in 10 minutes.

[HaloFour]

@springy76

I don't think that LINQPad should mess with or even change C# code.

I'm not suggesting this, only that LinqPad could flatten the heirarchy in the view.

And I don't see any caveat because nothing hinders you to skip that language feature and do it by hand as before.

The compiler still has to detect these situations individually and handle them, even if they are errors. And the spec has to be updated to very strictly define all of these rules and caveats. The fact that the developer can choose to not use the feature doesn't weigh into the work required to implement, but the more cases that prevent using the feature would certainly impact whether or not implementation is worth the effort.

I'm still firmly in the camp that this feature is one that should be solved in the visualization or data binding. The language shouldn't have to jump through hoops to improve the user experience of one specific tool like LinqPad. They could probably implement this feature in a matter of weeks whereas implementing it in the compiler would more likely take months if not years, assuming anyone from the compiler team is even willing to champion the proposal through the design process let alone actually implement it.

[svick]

I don't think that LINQPad should mess with or even change C# code.

I don't think @HaloFour was suggesting LINQPad should do that. But LINQPad does have ways to customize the displayed output. Here is a quick example:

Consider this code:

var people = new[] { new Person("springy", "76"), new Person("Halo", "Four") };
people.Select(p => new { p, FullName = $"{p.FirstName} {p.LastName}" }).Dump();

This produces:

But if you put the following code into LINQPad's My Extensions:

static object ToDump(object input)
{
    IDictionary<string, object> expando = Util.ToExpando(input);
    
    if (expando.Keys.Any(k => k.EndsWith("_e")))
    {
        IDictionary<string, object> result = new ExpandoObject();
        
        foreach (var kvp in expando)
        {
            var key = kvp.Key;
            if (key.EndsWith("_e"))
            {
                string keyPrefix = key.Substring(0, key.Length - 2);
            
                IDictionary<string, object> expanded = Util.ToExpando(kvp.Value);
                foreach (var expandedKvp in expanded)
                    result.Add($"{keyPrefix}.{expandedKvp.Key}", expandedKvp.Value);
            }
            else
            {
                result.Add(kvp);
            }
        }
        
        return result;
    }

    return input;
}

And then change the code so that the property name ends with _e:

people.Select(p => new { p_e = p, FullName = $"{p.FirstName} {p.LastName}" }).Dump();

The result becomes:

And I don't see any caveat because nothing hinders you to skip that language feature and do it by hand as before. […] I guess someone who knows how to code Roslyn features would do that in 10 minutes.

New language features are very expensive. Even if someone really managed to implement a basic version of this feature quickly, you still have to make sure sure the feature is tested, works well with IntelliSense, is well documented, is maintained forever etc. And even then, it would bloat the language. C# is already a fairly big language, making it harder to learn is also a cost that should be considered.

This pretty much guarantees that features that are useful only in a very limited set of use cases won't be implemented. Especially if they have decent workarounds.

[CyrusNajmabadi]

which finally are displayed in a data grid

if your data grid already understands anonymous types... wouldn't it be easier to modify it so that it knows how to flatten in cases like this and do what you want? After all, the moment you have "include all" you'll have the person who says "well... i want everything except this one guy" or "if it's in this view only project this subset of values..." etc. etc. It feels better if this sort of extraction logic is done in library code instead of in the language in a way that def won't be a good enough fit for most use cases.

[alrz]

looks a lot like ES spread operator,

var x = { a: 1, b: 2 }, y = { c: 3, d: 4 }
console.log({...x, ...y}); // {a: 1, b: 2, c: 3, d: 4}

relates to #424

[MgSam]

You could easily make a helper utility method to do this for you and use dynamic or a Dictionary instead of an anonymous type.