[Proposal] Implicit lambda parameter and trailing lambda in C#

[ronnygunawan]

var filtered = items.Where { Price > 9.99m }
                    .OrderBy { Name }
                    .ToList();

Implicit lambda parameter:

• Allow omitting () => when lambda has no parameter.
• Allow omitting arg1 => when lambda has only one parameter.
• Lambda with implicit parameter must always be enclosed in braces.
• If lambda is ambiguous between () => and arg1 =>, then implicit parameter can't be used.
• Members of implicit parameter can be directly used without member access operator, and will also hide names from enclosing type.
• The implicit parameter can be accessed using value keyword.
• async can be placed before the opening brace.
• this is unaffected. It still refers to enclosing type.

Trailing lambda:

• If last parameter of a method is a lambda with implicit parameter, then the lambda can be written after the closing parentheses.
• If the method only have one such parameter, then the parentheses can be omitted too.
• Trailing lambda can be used in constructors as long as there is no overload that can cause conflict between trailing lambda and object initializer. eg:

class Foo {
    public Foo(int x) { }
    public Foo(int x, Func<int, bool> f) { }
}

var foo = new Foo(10) { value % 2 == 0 }; // this is illegal because Foo has a
                                          // shorter constructor without the trailing lambda.

var foo = new Foo(10, f: { value % 2 == 0 }); // this is fine

Examples:

class Item {
    public string Name { get; set; }
    public decimal Price { get; set; }
}

Functions

// normal lambda
var filtered = items.Where(i => i.Price > 9.99m)
                    .OrderBy(i => i.Name)
                    .ToList();

// with implicit lambda parameter
var filtered = items.Where({ Price > 9.99m })
                    .OrderBy({ Name })
                    .ToList();

// with trailing lambda
var filtered = items.Where { Price > 9.99m }
                    .OrderBy { Name }
                    .ToList();

Actions

// normal lambda
items.ForEach(i => {
    Debug.WriteLine(i.Name);
    Console.WriteLine(i.Price);
});

// with implicit lambda parameter
items.ForEach({
    Debug.WriteLine(Name);
    Console.WriteLine(value.Price); // 'value' can be omitted
});

// with trailing lambda
items.ForEach {
    Debug.WriteLine(Name);
    Console.WriteLine(value.Price); // 'value' can be omitted
};

Method with multiple lambda

// normal lambda
var priceByName = items.ToDictionary(i => i.Name, i => i.Price);

// with implicit lambda parameter
var priceByName = items.ToDictionary({ Name }, { Price });

// with trailing lambda
var priceByName = items.ToDictionary({ Name }) { Price };

Get creative with trailing lambda

// VB-style With block
// note: following methods are not System.Console's static methods
With (console) {
    WriteLine("Hello World");
    BackgroundColor(ConsoleColor.Green);
    WriteLine("I am Green");
};

// fire and forget
Task.Run async {
    await Task.Delay(10000);
};

// foreach value in Range
ForEach(0..100) {
    Console.WriteLine(value);
};

[HaloFour]

Very similar to #1151

Kotlin and Scala both have a flavor of this feature (or set of features which can be combined to achieve this kind of syntax) and it can be useful to define DSL-like syntax. Although, IMO, Scala takes it a bit too far as you can omit the dot operator (sometimes) and you can omit the parenthesis (sometimes).

[ronnygunawan]

#1151 went too far imo, it retargets what this refers to. In my opinion, the ability to retarget this doesn't fit in C#.

[orthoxerox]

@ronnygunawan wrll, your suggestion retargets value instead. Retargeting this or at least bringing the members of the parameter into scope would be very useful for writing DSLs.

[ronnygunawan]

@orthoxerox well, I think both retargeting value and this has their own problems then. Retargeting value limits lambda's usability when used inside a property setter, while retargeting this hides the original this from enclosing type.

Kotlin and Java solve the this retargeting problem using EnclosingClassName@this, and for the value retargeting problem, value keyword can be replaced by a new keyword it.

[marchy]

Is this on the consideration list for C# 11 / C# 12?

The RemObjects C# compiler supports this Trailing Closures feature quite nicely, and Swift and Kotlin have supported this from the get-go (5+ years now). Would be great to see C# catch up to this modern must-have that can unlock all sorts of DSL-style APIs.

NOTE: Swift has since extended to support multiple trailing closures (full feature spec), thus directly supporting scenarios such as the example given above:

STRETCH: Not sure if compatible with C# named parameters overall, but being able to optionally specify those as well would make it these much more readable/useful as well.

Some very useful real-world examples from functional-style utilities:

//
// EXAMPLE 1
//
// current lambdas
DateTimeOffset rangeEndDate = endDateTime?.IfNotNull( endDateTime_ =>
		endDateTime_.StartOfDay() - ((crossesMidnight) ? 1 : 0).Days(),
	otherwise: () => startDateTime.StartOfDay() );

// with trailing lambda
DateTimeOffset rangeEndDate = endDateTime?.IfNotNull(
	value.StartOfDay() - ((crossesMidnight) ? 1 : 0).Days()
){ startDateTime.StartOfDay() };

// with multiple & named trailing lambdas (STRETCH)
DateTimeOffset rangeEndDate = endDateTime?.IfNotNull {
	value.StartOfDay() - ((crossesMidnight) ? 1 : 0).Days()
}, otherwise: { startDateTime.StartOfDay() };


//
// EXAMPLE 2
//
// current lambdas
GeoCoordinate? coordinate = Try.CatchingAsNull<ArgumentOutOfRangeException, GeoCoordinate?>( () =>
	new GeoCoordinate( place.geoCoordinate.latitude, place.geoCoordinate.longitude ),
@catch: x => { // NOTE: indentation hack to make it "feel" like a trailing lambda
	Log.LogError( $"Geo-coordinate for content #{attraction.id} out of bounds: ({place.geoCoordinate.latitude}, {place.geoCoordinate.longitude}). Error: {x.Message}" );
});

// with trailing lambda
GeoCoordinate? coordinate = Try.CatchingAsNull<ArgumentOutOfRangeException, GeoCoordinate?>( 
	new GeoCoordinate( place.geoCoordinate.latitude, place.geoCoordinate.longitude )
){ // NOTE: no indentation hack. Trailing lambdas naturally style back to the containing statement's indentation
	Log.LogError( $"Geo-coordinate for content #{place.id} out of bounds: ({place.geoCoordinate.latitude}, {place.geoCoordinate.longitude}). Error: {value.Message}" );
};

// with multiple & named trailing lambdas (STRETCH)
GeoCoordinate? coordinate = Try.CatchingAsNull<ArgumentOutOfRangeException, GeoCoordinate?>{
	new GeoCoordinate( place.geoCoordinate.latitude, place.geoCoordinate.longitude )
}, @catch: x => {
	Log.LogError( $"Geo-coordinate for content #{attraction.id} out of bounds: ({place.geoCoordinate.latitude}, {place.geoCoordinate.longitude}). Error: {x.Message}" );
};

[D0ctorWh0]

This could be very useful to convert code in fluent style into something easier to read and write. For example this

FluentQuery
	.ConnectionString("connectionString")
	.StoredProcedure("LoadData")
	.Parameters(c=>c
		.AddParameter("ParName1", "ParValue1")
		.AddParameter("ParName2", "ParValue3")
		.AddParameter("ParName3", "ParValue3")
		)
	.Execute();

into this

FluentQuery
	.ConnectionString("connectionString")
	.StoredProcedure("LoadData")
	.Parameters
	{
		AddParameter("ParName1", "ParValue1")
		AddParameter("ParName2", "ParValue3")
		AddParameter("ParName3", "ParValue3")
	}
	.Execute();

or even this

FluentQuery
{
	ConnectionString("connectionString")
	StoredProcedure("LoadData")
	Parameters
	{
		AddParameter("ParName1", "ParValue1")
		AddParameter("ParName2", "ParValue3")
		AddParameter("ParName3", "ParValue3")
	}
	Execute()
};

It seems to me it looks much easier to write and read.

[pelletburner]

Would allow for much cleaner use of Parallel.ForEach and several AOP-like patterns, too. I support this.

[tmteam]

I write a lot of code in Kotlin, where this syntax exists - and this is a game changer.

1. it allows you to move away from the fluent api towards the DSL api. In Compare to Kotlin - it is HUGE benefit of Kotlin

2. it is critical for the functional style of writing code. Imagine 3 or 4 nested lambdas, ugly mess - that is my everyday live

3. it is critical for Structural concurrency tasks. Here, braces are boundaries to concurrency scope, so it keeps code clean

[jantajov]

So, is this conaidered for upcoming c# releases?

[CyrusNajmabadi]

Fwiw, I would expect first to see a prototype of such a ui framework showing how it would want to be built with lambdas/delegates, and that there was a serious view that such a path would be desirable and viable. If that existed, the idea of a trailing lambda arg (and potentially other lambda improvements) could be more desirable.

But it's certainly not something that is going to see interest without firm belief it would actually be used and supplants the current patterns.

[CyrusNajmabadi]

@marchy that was in regards to this being driven by personal anecdotes vs a large set of feedback indicating widespread desire from the community.

We listen closely to feedback, but that also means we see which areas have high interest and which do not.

As an example, while you may not like primary constructors, or believe they were worthwhile, that doesn't jive with the interest and feedback we got on those.

That's ok though. Any decisions we make will certainly not align with all our users. We need to listen, engage, and make judgement calls, knowing that some will disagree and wish our efforts were spent elsewhere.

If it helps, I've proposed many a language feature myself, only to see little interest out value seen by others. That's ok. My goal at that point is to then see what I can do to make things more palatable for a larger group (which often hasn't been possible). That's the fun and challenge of it all.

[333fred]

It doesn't appear to me that Cyrus was specifically responding to the comment you linked; if he was, he would have responded there. His comment is also not a personal attack, as calling people "ignorant" is. That is a clear violation of our code of conduct. Again, please refrain from personal attacks.

[CyrusNajmabadi]

@marchy we have a code of conduct here that we ask people to abide by. Both in terms of people and posts, easily 99.99% go through (probably higher). Please just keep things civil and on topic, and please just remember that disagreement and differing opinions are a good thing. It's through that process that we come up with better designs, and more long lasting ideas that fit well with a language that is already 25 years old, and wants to keep going at least double that :-)

Thanks!