Proposal: Introducing the LINQ 'derive' Keyword

[sangeethnandakumar]

LINQ Projection

In LINQ, projection is a common operation where we shape the output of a query to meet specific requirements. Typically, we use the select clause to create new objects with the desired properties. Here's an example:

var result = from order in orders
            join customer in customers on order.CustomerId equals customer.CustomerId into custGroup
            from customer in custGroup.DefaultIfEmpty() // Left Join
            where customer != null && customer.City == "New York"
            select new Customer
            {
                OrderId = order.OrderId,
                CustomerName = customer != null ? customer.Name : "Unknown",
                TotalAmount = order.TotalAmount,
                // ... (tons of other properties)
            };

Potential Improvement Area

• However, there are scenarios where we need to modify specific properties during the projection.
• The issue with the select approach just projects the instance or allow us to create new instance
• This means that we have to specify every property we want in the result, Even if we need to modify one property.
• When dealing with objects with numerous properties, this can be very cumbersome and error-prone.

The Need for Data Mutation in Projections

What if we could seamlessly mutate specific properties during the projection without specifying all properties explicitly?

Introducing the derive Keyword

I'm proposing the introduction of a new LINQ keyword, derive to enable data mutation during projections. The derive keyword is designed to enhance the expressiveness and efficiency of LINQ. Here's how it works:

var result = from order in orders
            join customer in customers on order.CustomerId equals customer.CustomerId into custGroup
            from customer in custGroup.DefaultIfEmpty() // Left Join
            where customer != null && customer.City == "New York"
            derive customer with {
                TotalAmount = order.TotalAmount * 10,
                // ... (Other properties that remain unchanged. No need to specify them)
            };

In this example, we use the derive keyword to modify the TotalAmount property of the customer object.
This enhancement allows us to mutate data while preserving all other properties, eliminating the need to repeat them in the projection.

The introduction of the derive keyword not only streamlines LINQ queries but also provides a clear signal to code analyzers that data mutation is occurring.

I believe that the derive keyword is a valuable addition to LINQ, simplifying data manipulation, improving code clarity, and enhancing the overall development experience.

I personally felt this was a required feature. Here are some people also faced similar ones. All answers seems some sort of workarounds

1. https://stackoverflow.com/questions/4399284/linq-select-an-object-but-change-some-properties-without-creating-a-new-object
2. https://stackoverflow.com/questions/1776387/using-linq-to-update-a-property-in-a-list-of-entities
3. https://stackoverflow.com/questions/23399657/change-the-property-of-objects-in-a-list-using-linq

and more...

To be functionally pure, your linq would not alter the data that it is working on. That's why I'm thinking of derive keyword to explicitly cite it's getting modified

[svick]

Personally, I don't see a reason to have a LINQ-specific derive keyword, when we already have a with keyword that can be used in LINQ exactly the way you want. Currently, it only works if the type in question is a record, but that could be expanded in the future (see #162).

[colejohnson66]

I personally would rather have select customer with than add some new “derive” syntax

[sangeethnandakumar]

Ya the only limitation I see is with only works with Records not Classes. If that will be addressed later this proposal is not required it seems to me