Proposal: special syntax for lambdas as last arguments in invocation expressions (for DSLs)

[orthoxerox]

Warning: lots of Kotlin-inspired sugar.

Rationale: C# as it is doesn't support DSLs that well. Several features in Ruby, Groovy and Kotlin allow developers to author code that looks like native constructs.

1. Lambdas with receivers.

Lambdas can have their first parameter be treated as an implicit receiver inside the body. This affects name resolution in lambda body: implicit references to this of the declaring method are not available inside the body of a lambda. @ is used as an alias of the receiver parameter, this is used to refer to the receiver of the declaring method and all symbols not resolved as lambda locals are resolved as implicit lambda receiver members before other options are tried.

Methods indicate they accept lambdas with receivers by prefixing the parameter type with this, e.g., Action<this Customer> or Func<this Customer, bool> (this is later compiled as an attribute on the parameter). Such types cannot be used as types of locals, fields, return values or properties.

Lambda declarations in positions where an implicit receiver lambda is expected omit this parameter altogether (i.e., single-parameter lambdas look like zero-parameter lambdas).

Such lambdas are not very useful by themselves, but serve as a stepping stone for the second change.

2. Lambdas as last arguments of an invocation expression.

Zero parameter lambdas (including single parameter lambdas with implicit receivers) passed as the last parameter to a method call can be written outside the parentheses without () =>. If this invocation expression is being parsed as an expression statement then the semicolon is optional as well.

When zero parameter lambdas are passed as any other parameter, they can still be written outside the parentheses without () => as long as all other parameters are explicitly named.

someMethod(arg1, arg2, x => {
    statement(x);
    x.statement;
});

//if x is marked as an implicit receiver
someMethod(arg1, arg2) {
    statement(@);
    statement; //or @.statement;
}

Task.Run(() => {
    Console.WriteLine("Starting");
    DoStuff();
    Console.WriteLine("Done");
}, token);

Task.Run(cancellationToken: token) {
    Console.WriteLine("Starting");
    DoStuff();
    Console.WriteLine("Done");
}

Return statements are disallowed in such lambda bodies to prevent confusion.

Expression-bodied lambdas must have their bodies wrapped in {} as well. If they are the only argument, then the parentheses are optional as well.:

f(xs.Select(x => x + 2));

f(xs.Select { @ + 2 });

Examples:

//C# 7.2
var winners = customers
    .Where(c => c.Status == CustomerStatus.VIP)
    .SelectMany(c => db.GetOrders(c))
    .Where(o => o.TotalPrice.AsUSD() > 10000)
    .Shuffle()
    .Take(10);

//c# vNext
//We get shorthand lambdas for free!
var winners = customers
    .Where { Status == CustomerStatus.VIP }
    .SelectMany { db.GetOrders(@) }
    .Where { TotalPrice.AsUSD() > 10000 }
    .Shuffle()
    .Take(10);

//C# 7.2
Task("Clean")
    .Does(() =>
{
    CleanDirectory(buildDir);
});

Task("Restore-NuGet-Packages")
    .IsDependentOn("Clean")
    .Does(() =>
{
    NuGetRestore("./src/Example.sln");
});

Task("Build")
    .IsDependentOn("Restore-NuGet-Packages")
    .Does(() =>
{
    if(IsRunningOnWindows())
    {
      // Use MSBuild
      MSBuild("./src/Example.sln", settings =>
        settings.SetConfiguration(configuration));
    }
    else
    {
      // Use XBuild
      XBuild("./src/Example.sln", settings =>
        settings.SetConfiguration(configuration));
    }
});

Task("Run-Unit-Tests")
    .IsDependentOn("Build")
    .Does(() =>
{
    NUnit3("./src/**/bin/" + configuration + "/*.Tests.dll", new NUnit3Settings {
        NoResults = true
        });
});

//C# vNext
//NB: This is not 100% equivalent to the code above.
//    Task(string) method has been replaced with
//    Task(string, Action<this TaskBuilder> action)
Task("Clean") {
    Does {
        CleanDirectory(buildDir);
    }
}

Task("Restore-NuGet-Packages") 
{
    IsDependentOn("Clean");
    Does 
    {
        NuGetRestore("./src/Example.sln");
    }
}

Task("Build") 
{
    IsDependentOn("Restore-NuGet-Packages");
    Does 
    {
        if(IsRunningOnWindows())
        {
          // Use MSBuild
          MSBuild("./src/Example.sln")
          {
            Configuration = configuration;
          }
        }
        else
        {
          // Use XBuild
          XBuild("./src/Example.sln")
          {
            Configuration = configuration;
          }
        }
    }
}

Task("Run-Unit-Tests") 
{
    IsDependentOn("Build");
    Does 
    {
      NUnit3("./src/**/bin/" + configuration + "/*.Tests.dll", new NUnit3Settings {
        NoResults = true //I wonder if object initializers could get the same treatment
        });
    }
}

[jnm2]

I do wish C# was more concise, often in Cake but not just in Cake. The whole necessity of passing new NameOfTheCurrentCommandSettings { Foo = 42 } to avoid breaking changes and the .Does(() => { }) lambdas.
I don't know; still thinking.

[HaloFour]

f(xs.Select { x + 2 });

.Where { Status == CustomerStatus.VIP }

What about this proposal differentiates the very different behavior between these two statements? Why is x the lambda parameter but Status is a property of some implicit this lambda parameter?

I really don't like the idea of the meaning of this being hijacked in this manner. It feels very JavaScript, and in a very not-good way.

[MkazemAkhgary]

string Status = "a";
public void Method()
{
    string Status = "b";
    var query = customers.Where { Status == CustomerStatus.VIP };
}

so here Status in Where { Status == CustomerStatus.VIP };
refers to x.Status, what if you wanted to access either of local or global variables in that context?

[orthoxerox]

@HaloFour typo, fixed

[iam3yal]

In Kotlin the following:

someMethod(arg1, arg2, x => {
    statement(x);
    x.statement;
});

Would be something like this:

someMethod(arg1, arg2, {
    statement(it.x);
    it.x.statement;
});

I really like the way Kotlin does things, it reduces code clutter quite a bit, thus make the code easier to read but then again it's a newer language, they probably learnt a lot from C# and other languages.

Personally, I would really like to have something like this:

someMethod(arg1, arg2, {
    statement(_.x);
    _.x.statement;
});

But I wouldn't mind following Kotlin and have it iff it would be feasible as a contextual keyword.

[tmteam]

Actually it will be even simpler in kotlin:

Kotlin:

someMethod(arg1, arg2) {
    statement(it.x)
    it.x.statement
}

And it becomes more valuable when there is nesting:

Kotlin:

someMethod(arg1, arg2) { it->
    statement(it.x)
    it.doSome { options->
         println(options)
         println("end")
    }

}


C#:

someMethod(arg1, arg2, x => {
    statement(x);
    x.DoSome( options=>{
         WriteLine(options)
         WriteLine("end")
    });
});

[iam3yal]

@orthoxerox I still think you have typo there.

The following:

.Where { Status == CustomerStatus.VIP }

Should be

.Where { this.Status == CustomerStatus.VIP }

Isn't?

[orthoxerox]

@eyalsk No, Status is implicitly resolved to be this.Status.

[MkazemAkhgary]

I think this can be achieved by #91. I'm not trying to be negative here, but such implicit reference can be ambiguous with other local or global literals.

.Where(@.Status == CustomerStatus.VIP)

this also doesn't require any change in method signature.

[iam3yal]

@orthoxerox Okay, interestingly confusing. 😆

How it's going to work with say intellisense?

[orthoxerox]

@eyalsk How does it work in method bodies?

@MkazemAkhgary shorthand lambdas are just a bonus that falls out of these changes, the main goal is to be able to write "while-like" or "using-like" custom commands.

[orthoxerox]

@HaloFour I wouldn't have hijacked this this way, but it's important to be able to introduce a special scope inside the lambda to correctly resolve names valid in this scope without polluting the outer scope or resorting to prefixes. This can be done via a pseudo-receiver, and this naturally appears as a consequence. It would've been even stranger if you could say Foo() and see that it resolves to somethingImplicit.Foo(), but were not able to refer to somethingImplicit in any way.

[iam3yal]

@orthoxerox What's going to happen in this case? I mean, how do you access a member of the class with the same name within the body of the lambda? or you expect that in this case people will use the traditional syntax?

class Foo {
	public int Status { get; set; }

	public void Bar()
	{
		var winners = customers
			.Where { Status == ????.Status }
		    .SelectMany { db.GetOrders(this) }
		    .Where { TotalPrice.AsUSD() > 10000 }
		    .Shuffle()
			.Take(10);
	}
}

[miyu]

Capture var self = this to a local worst case, then use self in the closure. It's an edge case but really not that bad.

[orthoxerox]

@eyalsk yes, I would expect people to use the traditional syntax.

[iam3yal]

@orthoxerox Okay.

In general, I think the idea is good and i really like to get rid of the "ceremony" of lambdas and even more in generics and other places in C# but I do find the case where all members are "exported" and implicitly available in the body confusing, I don't know, maybe it's just a matter of getting used to.. but it may also be the case of taking a good idea a bit too far.

[orthoxerox]

@eyalsk the proposal is less about shorthand lambdas and more about providing a way to write constructs like

Foo("foo") {
    Bar();
    Baz();
    Quux();
}

where Bar, Baz and Quux are available and visible only inside that Foo block.

Shorthand lambdas are just a side effect of adding features to the language to support the other use case.

[orthoxerox]

@gafter How did your implementation deal with return statements?

[gafter]

Exception-handling (throwing and catching exceptions) is exceptionally efficient in the Java runtime. Creating exceptions not so efficient because it captures a stack trace. My implementation allocates an exception object lazily, when needed, without capturing a stack trace, and throws it, catching it in the enclosing construct where the return statement semantics are executed.

This can even be made to work in concurrent control constructs, where the exception needs to be shuttled from one thread to another. See http://gafter.blogspot.com/2006/10/concurrent-loops-using-java-closures.html . I believe the prototype contains an implementation of this concurrent loop construct.

[gafter]

In case that did not answer your question, a return statement returns from the enclosing method, not the implicit lambda. Similarly break and continue work "as expected".

[orthoxerox]

@gafter Thanks, your answer was very clear. So basically the code would be lowered to something like this, wouldn't it?

foo(bar) {
    return 1;
    break;
    continue;
}

try {
    foo(bar, () => {
        throw ControlFlowExceptionCache.Return(1);
        throw ControlFlowExceptionCache.Break();
        throw ControlFlowExceptionCache.Continue();
    });
}
catch (ReturnException<int> ex) {
    return ex.ReturnValue;
}
catch (BreakException ex) {
    break;
}
catch (ContinueException ex) {
    continue;
}

Do you happen to know why JetBrains didn't do that in Kotlin?

[gafter]

Something like this http://gafter.blogspot.com/2006/09/control-abstraction.html

[orthoxerox]

@gafter Yes, but with the option to change the default receiver inside the block, so you can say

Panel {
    Color = #FF0000;
    Button {
        Text = "Press me"
    }    
}

[rollsch]

Any updates on this? Looks very neat.

[lucasteles]

That would be very good for MAUI

One of the premises is to have declarative UI that end up needing some kind of DSL

This proposal could help a lot

[CyrusNajmabadi]

This is a mythical man-month issue. You can't just throw more teams at it hoping it will go faster :-/

[CyrusNajmabadi]

Any updates on this? Looks very neat.

There are no updates on this. This would need to be championed by someone to move anywhere.

[marchy]

Is this on the consideration list for C# 11?

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.

[marchy]

Posted a more thorough set of real-world examples on related issue #2781.
Not sure which should be the active one so linking both.

[333fred]

Neither is an active issue championed by a member of the LDM. I do have some interest in it, and likely would champion if someone wanted to write up a specification for it. It would definitely not meet the bar for C# 11, however. That would have needed to happen this time last year.

[marchy]

@333fred are you aware of any .NET frameworks/APIs that could benefit from this?

Perhaps we could start itemizing some of these to help drive momentum, similar to how the EF team is tracking features blocked on lack of support for modern expression tree constructs.

No idea what getting a spec spun up would entail.
Are you referring to inside or outside MS?

[333fred]

I am not aware immediately.

A spec can be written by anyone. There is an issue template that covers it.

[orthoxerox]

if someone wanted to write up a specification for it

If someone wrote up a specification 😛, I don't doubt many people want to, but won't. I'll see what I can come up with.

[marchy]

Here are a handful of examples sweeping through our codebase to kick things off:

Frameworks Improved

LINQ

Example: All Select / Where etc. operators

IEnumerable<Thing> things = (await eventsQuery
	.Select( _ => new {
		_.ID,
		_.Name,
		_.DALPlace,
	}).ToListAsync()
).Select( _ => new {
	_.ID,
	_.Name,
	Place = JsonConvert.DeserializeObject<PlaceDBO>( _.DALPlace ),
});

⇨ ⇨ ⇨

IEnumerable<Thing> things = (await eventsQuery.Select {
	new {
		_.ID,
		_.Name,
		_.DALPlace,
	}
}.ToListAsync()).Select {
	new {
		_.ID,
		_.Name,
		Place = JsonConvert.DeserializeObject<PlaceDBO>( _.DALPlace ),
	}
};

Task API

Example: Continuations

return UnitOfWork.SaveAsync()
	// send out notifications
	.ContinueWith( task => {
		// do nothing if failed
		if( task.IsFaulted )
			return null;

		return NotificationService.SendOutNewMessageNotifications( chat, newMessage );
	});

⇨ ⇨ ⇨

return UnitOfWork.SaveAsync()
	// send out notifications
	.ContinueWith {
		// do nothing if failed
		if( value.IsFaulted )
			return null;

		return NotificationService.SendOutNewMessageNotifications( chat, newMessage );
	};

EF Core

Examples:

1. DbContext model builders
2. Strategy executions

// 1: model builders
modelBuilder.Entity<Account>( account => {
	account.HasKey( _ => _.ID );
	account.HasAlternateKey( _ => _.ClientID );
	account.Property( _ => _.ClientID )
		.ValueGeneratedOnAdd();
	account.HasIndex( _ => _.ClientID )
		.IsUnique();
	account.Ignore( _ => _.HasPhoneNumber );
	account.Property( _ => _.PhoneNumber )
		.HasMaxLength( ColumnLength_CanonicalPhoneNumber )
		.HasConversion(
			// TODO(arch): Should we also serialize the user-friendly number into here? Might be needed later when we allow users to change their account phone numbers (unless always want clients to do this)
			model => (model != null) ? model.CanonicalNumber : null,
			raw => raw.NullOr( _ => new PhoneNumber( _, null )));
	account.HasIndex( _ => _.PhoneNumber )
		.IsUnique();
});

⇨ ⇨ ⇨

modelBuilder.Entity<Account> {
	_.HasKey( _.ID );
	_.HasAlternateKey( _.ClientID );
	_.Property( _.ClientID )	.ValueGeneratedOnAdd();
	_.HasIndex( _.ClientID ).IsUnique();
	_.Ignore( _.HasPhoneNumber );
	_.Property( _.PhoneNumber )
		.HasMaxLength( ColumnLength_CanonicalPhoneNumber )
		.HasConversion(
			// TODO(arch): Should we also serialize the user-friendly number into here? Might be needed later when we allow users to change their account phone numbers (unless always want clients to do this)
			model => (model != null) ? model.CanonicalNumber : null,
			raw => raw.NullOr( _ => new PhoneNumber( _, null )));
	_.HasIndex( _.PhoneNumber )
		.IsUnique();
};

// 2: execution strategy
ExecutionStrategy.ExecuteAsync( async () => {
	await using IDbContextTransaction transaction = await BeginTransaction();

	return await operation( transaction );
});

⇨ ⇨ ⇨

ExecutionStrategy.ExecuteAsync() async {
	await using IDbContextTransaction transaction = await BeginTransaction();

	return await operation( transaction );
};

AutoMapper (not MS, but super popular/useful and would greatly benefit)

Examples:

1. Single mappings
2. Chained mappings

// 1: simple mapping
config.CreateMap<PlaceWhere, WhereDBO>()
	.ForMember( _ => _.Type, mapping => mapping.MapFrom( _ => WhereType.Place ));

⇨ ⇨ ⇨

config.CreateMap<PlaceWhere, WhereDBO>()
	.ForMember( _.Type ){
		value.MapFrom{ WhereType.Place }
	};

// 2: chained mappings
config.CreateMap<HappeningMemberState, HappeningMemberStateDBO>()
	.ForMember( _ => _.MemberRef, mapping => mapping.MapFrom( _ => _.Member ))
	.ForMember( _ => _.InvitedBy, mapping => mapping.Ignore() ) // NOTE: This is mapped at a higher level instead (ie: by Plan entity)
	.ForMember( _ => _.Computed_UnreadPlanUpdates, mapping => mapping.MapFrom( _ => _.Computed_UnreadHappeningUpdates ));

⇨ ⇨ ⇨

config.CreateMap<HappeningMemberState, HappeningMemberStateDBO>()
	.ForMember( _.MemberRef ){ _.MapFrom{ _.Member }}
	.ForMember( _.InvitedBy ){ _.Ignore() }
	.ForMember( _.Computed_UnreadPlanUpdates ){ _.MapFrom{ _.Computed_UnreadHappeningUpdates }};

[bondsbw]

Are the curly braces necessary for expressions? Like with Select?

[HaloFour]

This implies some sigil to represent the lambda parameter as well, e.g. _.

To be honest, I don't really find these examples particularly compelling, but maybe that's just me. When you chain off of the lambda it just feels muddy what you're actually chaining on. I've seen better examples from Scala and Kotlin.

[CyrusNajmabadi]

My honest take is that the 'after' code looks quote confusing.

[Simplifier]

Is this proposal abandoned? Kotlin's lamdba syntax is so elegant and neat, it would be awesome to see it in c#

[CyrusNajmabadi]

@Simplifier No. This is not abandoned.

[marchy]

Please. Do this. Already.

Biggest missing feature in C# by a long-shot.

[Richiban]

I love this feature (I use it mostly in Kotlin but Swift and Scala have it too, amongst others) and I think C# would benefit greatly from its introduction.

Even better would be if somehow object initialiser expressions could be retconned into being trailing lambdas (inlined, of course) so that normal C# would be supported inside the expression:

var p = new Point 
{
	X = 4;

	if (someBool) 
	{
		Y = 5;
	}
}

This is a bit of a pain point around init properties where the property can only be set in the object initialiser but there's currently no way in C# to conditionally set a property.