Cascade expressions with 'then' and 'it'.

[JeroMiya]

Other similar issues:

• Proposal: Cascade notation (..) #1825 (This proposal started here as a comment to this existing proposal, but my proposal uses a different syntax than 1825, addresses a scope name resolution consistency issue, and is slightly more powerful through the use of two keywords instead of one token.
• [Proposal] Auto-fluent interface for void-return methods #781 (My proposal uses an explicit syntax, and thus does not change the meaning of void).
• add then keyword to improve readabilty #1619 (We both introduce then keyword, but the meaning is completely different).

Motivation

Declarative code can be slightly painful in C#, often requiring the use of temporary variables. Named constructor parameters, and initialization syntax, helps, but it is limited to just those for object initialization. Notably missing are methods that take the object as an argument and methods on the object itself. In either of those :

list.Add(new Foo(arg1: value1, arg2: value2) { Property1 = value3, Property2 = await GetValue4Async() });

// But I can't call a method on the Foo, subscribe to a click event, subscribe to an IObserbable, etc... before it gets added to the list, without a temporary variable:
var temp = new Foo();
await DoSomethingAsyncOnFoo(temp);
temp.DoDeferredInitialization(argument);
temp.Clicked += Item_Clicked;
temp.Clicks.Subscribe(() => Console.WriteLine("item was clicked");
list.Add(temp);

Also, if you have an object tree where you want a reference to part of the object tree, you also must make a temp variable, which breaks up the object tree expression, harming readability:

Content = new Widget() {
    this.entry = new Entry(placeholder: "Enter a value");
    Children = new Widget[] {
        new Label(text: "Hello"),
        this.entry,
        // rest of control tree
    }
}

Note how @VincentH-Net's CSharpForMarkup library has to introduce an extension method to address some of these issues:

// Execute some code on the instance before it's evaluated into the expression tree
new ListView { }.Invoke(l => l.ItemTapped += MyListView_ItemTapped);

// Assign out an instance without creating a temp variable
new ListView { }.Assign(out MyListView),

However, these solutions require hand-crafted Fluent APIs from extension methods, which are specific to the object tree types. This proposal introduces a general purpose solution to these problems and improves C#'s usability with declarative code.

Proposal

This proposal introduces two new keywords, then and it. it stands as a placeholder for an unnamed value in the context where one exists, as in this proposal, but could be used as such in other proposals (e.g. a hypothetical streamlining of lambda expression syntax for lambdas with one argument, as in scala or kotlin).

then is a keyword that follows an expression (eagerly evaluated) in the form of expression then statement, which itself becomes an expression (thus chaining is possible: expression then statement1 then statement2 is equivalent to (expression then statement1) then statement2). Such an expression would be called a "cascade".

The meaning of a cascade is as follows: first the expression to the left of then is evaluated, then the statement to the right of then. The value of the cascade expression is the value of the expression after the statement in the cascade is executed. Within the statement in a cascade expression, all accessible members of the expression object can be referenced without qualification (except for operators and indexers), unless there is a conflict with a name in the local scope within which the cascade expression lives:

private Entry entry;
public MyWidget() {
  Content = new Widget() {
       Children = new Widget[] {
           new Label(text: "hello"),
           new Entry() then TextChanged += Entry_TextChanged then this.entry = it,
           new StackLayout() {...etc...}

When it appears within a statement inside a cascade expression, the keyword it stands in for the value of the expression to the left of the then keyword. However, use of it explicitly is not necessary unless there is a conflict with a name in the local scope within which the cascade expression lives, or when using operators or indexers on the value of the expression:

class Foo {
    public int Length { get; set; }
    private int[] list;
    public Foo() {
        // Length references Foo.Length, it.Length references the int[].Length
        this.list = new int[] { 1, 2, 3} then Length = it.Length then Console.WriteLine($"The first item is {it[0]}.");
    }
}

Name conflicts are resolved with local variables/members taking precedence over the members of the target-expression object in a cascade expression. If you take a look at the example above, note how Length is a property of both Foo and int[]. In this case, just typing Length references the Foo.Length, whereas it.Length references the target expression object's Length property. In this case, the target expression object is an array of int.

Statements in a cascade expression can use async/await:

Content = new Entry() then Text = await GetTextFromServerAsync();

Cascade expressions can be chained. They are evaluated left-to-right:

Children.Add(new Entry()
    then Text = await GetTextFromServerAsync() 
    then Placeholder = await GetPlaceholderFromServerAsync(Text));

[franchyd]

In the following:

Children.Add(new Entry()
    then Text = new Text()
    then Placeholder = await GetPlaceholderFromServerAsync(Text));

Does the second then apply to the new Text() or the new Entry()

[JeroMiya]

Does the second then apply to the new Text() or the new Entry()?

It applies to the new Entry(). To nest cascades, use parenthesis:

Children.Add(new Entry()
    then Text = (new Text() then DoSomethingWith(it))
    then Placeholder = await GetPlaceholderFromServerAsync(Text));

[CyrusNajmabadi]

It applies to the new Entry(). To nest cascades, use parenthesis:

I actually uncertain how you grammatically could ensure that. Could you clarify? If 'then' is allowed after 'new entry()' how do you make the second 'then' not bind to new text()? The parser will be doing the exact same thing for new text() that it was doing for new entry(). Can you actually take the C# language and show the grammar changes necessary here? Thanks!

[JeroMiya]

Still working on the formal grammar changes needed. Informally, the keyword then is only valid with an expression to the left of it and to the right a conservative subset of statement. The cascade itself is an expression. The second then without a parenthesis starts another cascade, "closing off" the expression to the left of it, which in that case is another cascade.

I'm a little new to the C# grammar definition, so forgive me if this is off, but here's a rough go at it. The definition of cascade-statement is work in progress, as it is a subset of statement but there isn't a clean break out of statement types that allows me to exclude certain types of statements, requiring alternates. Informally: no semicolons outside of a block (semicolons in blocks are ok), no statement labels (e.g. labeled-statement is banned), no variable declarations (except in blocks), and limited jumps (just throws).

// A.2.4 Expressions

cascade-expression (new):
    expression "then" cascade-statement

primary-expression (just added "it"):
    "new" non-array-type "[" expression-list "]" rank-specifier* array-initializer?
    "new" array-type array-initializer
    literal
    identifier
    "(" expression ")"
    primary-expression "." identifier
    predefined-type "." identifier
    primary-expression "(" argument-list ")"
    primary-expression "[" expression-list "]"
    "this"
    "it"
    "base" "." identifier
    "base" "[" expression-list "]"
    primary-expression increment-decrement
    "new" type "(" argument-list ")"
    "typeof" "(" type-or-void ")"
    "checked" "(" expression ")"
    "unchecked" "(" expression ")"

expression (just added cascade-expression):
    expression "?" expression ":" expression
    expression "||" expression
    expression "&&" expression
    expression bar expression
    expression "^" expression
    expression ampersand expression
    expression expression-equality-operator expression
    expression expression-relational-operator expression
    expression "is" built-in-type
    expression expression-shift-operator expression
    expression plus expression
    expression minus expression
    expression "*" expression
    expression "/" expression
    expression "%" expression
    unary-expression
    unary-expression assignment-operator expression
    cascade-expression

The part I'm struggling with is the definition of cascade-statement, which is a limited set of statement expressions.

My work in progress:

// A.2.5 Statements:

cascade-statement (new):
    block
    try-statement
    "throw" expression?
    switch-statement
    constant-declarator
    using-statement
    "checked" block
    "unchecked" block
    statement-expression (I think)
    alternatives to if-statement, do-statement, for-statement, using-statement, and foreach-statement where embedded-statement (not allowed) is replaced by block, or else a pared down embedded-statement. Also a do-statement alternative without the semicolon.

[CyrusNajmabadi]

if you define things as:

cascade-expression (new):
    expression "then" cascade-statement

then, in your example, new text() then ... would parse as it's own cascade-expression. Right?

[CyrusNajmabadi]

Or, if you're trying to make it so that post-then no more'thens are allowed... then i think you're noticing how convoluted you'd need to make things to support this language feature.

[JeroMiya]

Yes, multiple thens are allowed, but the intent is that a then cannot be in a cascade-statement at the top level (it can be in a block or in parentheses), so when the second then is encountered it finishes off the cascade-statement, then the cascade-expression, then starts a new cascade expression using the previous one as the target expression.

[CyrusNajmabadi]

it can be in a block or in parentheses

So i could not do:

x ? new Entry() then ... : ...

?

[JeroMiya]

No, you can do that.

It's possible to pare down cascade-statement significantly if needed and still retain the usefulness of this syntax. For example, at a bare minimum you could just support block, though it would make them a bit noisy to use:

var x = y ? new Foo() then { RegisterFoo(it); } : cachedFoo;

Too many semicolons and braces for the simpler use cases. But you could add just a few additional cases, and use block for anything more complicated, removing all the control blocks and switch statements and loops (use a block for those):

var x = y ? new Foo() then RegisterFoo(it) : cachedFoo;
var x2 = new Foo() then it.DoSomething();
var x3 = new Foo() then this.field = it;
var x4 = new Foo() { Property = new Bar() then localVariable = it };
var x5 = new Foo() then await it.AsyncOperation() then Console.WriteLine("Operation done");
var x6 = new Foo() then {
    for(int i = 0; i < 20; i++) { it.Function(i); }
};
// maybe a few other simple cases?

Note that cascade-statement is its own definition and so it doesn't interfere with any other existing definition in the statements section.

[CyrusNajmabadi]

No, you can do that.

Ok. I guess i need to see what your grammar would actually be. I'm not quite getting it yet.

[CyrusNajmabadi]

Note that cascade-statement is its own definition and so it doesn't interfere with any other existing definition in the statements section.

The problem here is the recursion of:

cascade-expression (new):
    expression "then" cascade-statement

cascade-statement (new):
    ...
    statement_expression

statement_expression:
    invocation_expression
    ...

invocation_expression ... goes to ... expression

expression:
     ...
    cascade_expression

[JeroMiya]

Yes, I see the problem. Fundamentally the problem with my proposal is the ambiguity between the start of a new cascade expression and the continuation of an existing one. Additionally, although you haven't mentioned it, the it keyword also presents a problem w.r.t. local name resolution conflicts. I've been thinking about this for a bit and I think I may have a solution, but I would appreciate your feedback (which has been invaluable so far in helping refine this proposal). In summary, I remove the it keyword, return to left-right expression tree parsing for chained then keywords, and change to a lambda syntax for the body of the cascade, with an optional lambda argument.

// If you only need one cascade-statement, it can follow the 'then' keyword:
Widget Build(Context context) =>
    new Entry() 
        then TextChanged.Subscribe(newValue => Console.WriteLine($"Text changed to {newValue}");

// Note that with THIS modified proposal, we use the normal left-right parsing of expression trees
new Foo() then ChildComponent = new Component() then ChildComponentMethod("foo");

// OLD proposal: the above statement would be equivalent to this (but I 
// couldn't figure out a way to integrate that with the existing grammar):
// (new Foo() then ChildComponent = new Component()) then ChildComponentMethod("foo"); // ERROR Foo has no method named ChildComponentMethod

// NEW proposal: the above statement would be equivalent to this (follows from left-right parsing
// of the expression tree):
new Foo() then ChildComponent = (new Component() then ChildComponentMethod("foo"));

// If you need more than one cascade statement, they must be in a block. Within that block,
// accessible members of the target can be resolved without qualification,
// though local names take precedence:

// OLD proposal:
// new Foo() then FooMethod("Foo") then AnotherFooMethod("Foo");

// NEW proposal:
new Foo() then { FooMethod("Foo"); AnotherFooMethod("Foo"); };
    
// 'it' is removed from my proposal
// if you need a reference to the target expression, or to use an indexer, follow then with
// a full lambda expression with an argument:

// OLD Proposal:
// new Foo() then RegisterFoo(it);

// NEW Proposal:
new Foo() then it => RegisterFoo(it);
new Foo() then someOtherName => RegisterFoo(someOtherName);
new Foo() then newFoo => newFoo[12] = await GetValueAsync();
class Boo() {
  public string Text { get; set; }
  public Foo Property => new Foo() then it => { it.Text = Text; }
  // the above is equivalent to public Foo Property => new Foo() then it => { it.Text = this.Text; } where "this" is of type Boo
}

// Lambda expression argument must be inferred or else invariant to the target expression type
//new Foo() then (FooBaseType foo) => RegisterFooBaseType(foo); // ERROR, cascade body argument does not match target expression.

// note that the lambda is intended to be inlined in most cases. 
// When compiled, the compiler MAY lift the body of the lambda into the parent code

// this
new Foo() then FooMethod(12);

// should be compiled to the equivalent of this:
  var temp = new Foo();
  temp.FooMethod(12);

// not this:
((Foo it) => it.FooMethod(12))(new Foo());

// But you can still pass a delegate by reference. The compiler or JIT will inline if it can:
var x = (Foo it) => it.FooMethod(12);
var y = new Foo[] { new Foo() then x, new Foo() then x, new Foo() then CreateAFunctionDynamically(12) };

// Any inlining of the body of the lambda expression following "then" is
// an implementation detail or optimization of the compiler or JIT/AOT

[CyrusNajmabadi]

I thnk i've lost what problem we're actually trying to solve, and how this makes things better than today.

[JeroMiya]

Yep, it's important to remember the motivation for this suggestion. I explained a little bit of it in the original post, but I'll try to clarify as best I can.

In this case, I would like to make declarative code less painful on C#. "declarative" is a little ambiguous here, but what I mean by declarative code is any code that constructs a complex object/function tree. Could be a UI widget tree, or a build system, or any kind of pipeline or workflow API, such as one you might see in AI or machine learning or state machines, and so on.

Declarative code in C# is painful because most declarative code is actually a mix of declarative and imperative code. It's the mix that's painful in C# - anytime you need to mix a little imperative code into a declarative section of code in C#, you have to use cumbersome aids - temp variables, helper methods, extension methods, or redesign your API (if it is indeed your API to redesign) to be more "fluent". This is because you can't execute code on an unnamed object in your object tree before inserting it into the object tree - not without a temp variable or a helper method or an extension method. Or, by creating a perhaps overengineered "Builder" API that is "fluent".

Try this excercise to see what I mean. Find some of your own production Xamarin.Forms or WPF or UWP UI written in XAML (or find some on github) and TRY to convert the XAML to pure C#. BUT, you're not allowed to use: temp variables, helper methods, or extension methods. Your entire UI has to be defined after a Content = statement. I don't think it's possible - not unless your UI doesn't do databinding and isn't interactive at all.

When constructing an object in C# without a name for that object to reference it by (as is often done in declarative programming), you have basically three options for initializing that object: constructor parameters, property/field initializers, and using a helper method (including extension methods). If you want to assign a field to that instance, call a method on that instance, reference another object in the tree, use an indexer on that instance, or call another method on the instance itself, your ONLY option is a helper method or move that object initialization above the object tree as a temp variable. If you need to reference a parent object or another object in the tree, those too would need to be moved to temp variables. Until the entire tree is flattened out as temp variables and then constructed at the end. In other words, a real mess.

This proposal addresses that problem by introducing a way to insert some code after an object initialization or other expression without breaking out of the object tree expression via a helper method or temp variable. It improves the readability of the code by keeping related code together, as opposed to somewhere above in a temp variable or in a helper method. It reduces the need to design and implement cumbersome fluent builder APIs to make declarative programming tolerable.

[CyrusNajmabadi]

you have to use cumbersome aids - temp variables, helper methods, extension methods, or redesign your API (if it is indeed your API to redesign) to be more "fluent".

None of that seems cumbersome. And it doesn't seem any more cumbersome then using some new construct here AFAICT.

Try this excercise to see what I mean. Find some of your own production Xamarin.Forms or WPF or UWP UI written in XAML (or find some on github) and TRY to convert the XAML to pure C#. BUT, you're not allowed to use: temp variables, helper methods, or extension methods.

I don't see why that's interesting, or why i would even care to do that. It's like having someone come to your proposal and saying "ok... so cascade expressions are nice, but you're not allowd to used them for Xaml." Why would i be interested in framing things that way. It would be akin to someone saying "yeah, cascade exprs are great, if you're on C#1". But we're not. We're on C# 8 and there's tons of options to improve code and make it easier to write. Saying we need another feature here because you've arbitrarily carved out all the improvements since 1.0 seems super strange to me.

In other words, a real mess

I don't see any mess here. :)

This proposal addresses that problem by introducing a way to insert some code after an object initialization or other expression without breaking out of the object tree expression via a helper method or temp variable. It improves the readability of the code by keeping related code together,

I don't see how it's more readable. Heck, Roslyn itself has tons of lines like this, and it's pretty easy to grok.

as opposed to somewhere above in a temp variable

Why does a variable hurt readability? I honestly ask that as someone who has experience with a huge swatch of languages across may paradigms. I think this is one of the first times i've heard this being stated. And it's not like i haven't heard people talking about this space a lot. Indeed, it's often the reverse where people tend to find things confusing as jamming everything into one massive expression can actually make it harder to tell what's going on. Variables actually address this in a very natural way by allowing one to break up ideas that are too large and to operate on entities that are named effectively to abstract over that complexity and allow you to just work with something representing it instead.

to make declarative programming tolerable.

I don't see anything intolerable about declarative programming. The difference is that i don't see the need to make "everything an expression". I've actually used languages that have really pushed for that sort of thing, and they're jsut about as tolerable to use as others are.

[adamped]

I'm not quite understanding the problem. While removing white spaces makes it a little harder to read (as would removing white space in many situations), the precedence is always a simple chain from left to right. Each .. discards the result and returns the original receiver.

If you wanted the .. to run off a different object, you would implement brackets or parenthesis as appropriate.

I wouldn't expect the .. to run off Something or the Color.Black because that previous section's result is discarded and the original object is returned.

[HaloFour]

@adamped

I wouldn't expect the .. to run off "Something" or the Color.Black because that previous section's result is discarded and the original object is returned.

That's where the problem lies. There's no way for the compiler to know that the "previous section" is complete. As you say you have to introduce parenthesis to allow cascading on child expressions, something that C# has never required. It turns ugly fast. It doesn't even look good in Dart.

[adamped]

How would the compiler struggle to know when a section is complete? If Dart can do it, and I can visually/manually do it, its technically feasible, at least that can be confirmed. Unless C# has something different, that throws a spanner in the works, that I'm not seeing?

[HaloFour]

@adamped

Because any and all operators would apply to the subexpression first. That's how all C# syntax works today, including the dot operator.

Could C# be changed to make .. different? Sure. But that introduces a big inconsistency into the language.

[JeroMiya]

The issue with the original proposal wasn't related to whitespace specifically but with the recursion of the expression definition:

cascade-expression: expression "then" cascade-statement // or if you prefer: cascade-expression: expression ".." cascade-statement

Except that because cascade-expression is also an expression, when you come across another cascade token (either then or ..) it ends up parsing a new cascade expression instead of continuing the existing one.

I think Dart gets around this by limiting syntactically what can be to the left of the .. and to the right, such that it isn't recursive or ambiguous, but it's more limited.

[JeroMiya]

I think it should be noted too that the problems I'm describing above could also be solved with support of expression blocks, as in other languages, though I think implementing expression blocks in C# would cause all sorts of havoc to the grammar. It would look something like this:

override Widget Build() => new Shell(
  title: "Title",
  actionButtons: new ActionButton[] {
      { var button1 = new ActionButton(); button1.Pressed.Subscribe(Button1Pressed); button1; },
      { var button2 = new ActionButton(); button2.Pressed.Subscribe(Button2Pressed); button2; },
  }
}

C# doesn't even support immediately executing a lambda as an expression:

new ActionButton[] {
  // ERROR: method name expected
  (() => { var button1 = new ActionButton(); button1.Pressed.Subscribe(Button1Pressed); return button1; })(),

[theunrepentantgeek]

@adamped asked

While many are pointing out, why not use other methods, I'm wondering what other methods are as easy as cascading expressions?

I'd suggest reuse/expansion of the syntax we already have in C# for object initialization expressions: permit them to happen after any expression, instead of only after object construction, and slightly extend the statements permitted within.

Here's what some of the examples already given would look like ...

... though this one is just object initialization anyway ...

new Entry()
{
    Text = "Something",
    Color = Color.Black,
    TextChanged += Entry_TextChanged
}

new IconButton(...)
{
    Pressed.Subscribe(OpenFilters)
}

override Widget Build(BuildContext context) 
    => new Scaffold(
        appBar: new AppBar(
			title: new Text(""),
			centerTitle: true,
			actions: new Widget[] 
			{
				new IconButton(icon: new Icon(Icons.Filter))
				{
					Pressed.Subscribe(OpenFilters)
				},
				new IconButton(icon: new Icon(Icons.Notifications))
				{
					Pressed.Subscribe(OpenNotifications)
				},
				new IconButton(icon: new Icon(Icons.Account))
				{
					Pressed.Subscribe(OpenAccount)
				}
			}
		),
		body: BuildBody()
    );

I've assumed that Pressed is an event on IconButton, though that's never been confirmed by the OP.

To be clear - I still don't see a need for writing code in this style. If I was intent on writing obfuscated and hard to maintain code, designed to frustrate future maintenance developers, this is exactly what I'd do.

But, if wiser minds decide that C# needs to support this development style, let's do it in a way that's consistent with what's gone before, retaining the feel of the language.

[adamped]

I thought about extending the object initialization expressions, which I agree would suit the language better. It removes the ability to use it anywhere other than object initialization, but I'm not thinking of too many use cases where that would be much of a problem.

[JeroMiya]

@theunrepentantgeek I actually kind of like this suggestion, though this:

permit them to happen after any expression

Would probably be ambiguous in the grammar? And without that, you can't do composition with helper functions:

Button MakeCustomizedButton(string text) => new Button(text: text); // TODO: customize this
...
override Widget Build(BuildContext context) =>
  new Scaffold(
    title: new Text("Title"),
    body: new Column(
      children: new [] {
        new Button("Action1") { Click.Subscribe(OnAction1Clicked); } // this works with your proposal
        MakeCustomizedButton("Action2"), // But this doesn't? How to I subscribe to Click events?
        // cascades work with either
        new Button("Action3") then Click.Subscribe(OnAction3Clicked),
        MakeCustomizedButton("Action4") then Click.Subscribe(OnAction4Clicked),
      }
    )

Another minor issue would be an inability to pass the target expression object to another method, one of the main use cases. Or would this be allowed (using declaration syntax)?

// ...etc... inside a larger expression tree
// TrackOutOfBounds is some other method, maybe in the same class or via a static using, etc...
children: (var aiActor = new Actor() { TrackOutOfBounds(aiActor) }),

But this might be ambiguous since TrackOutOfBounds should be parsed as a member of the object being constructed to stay consistent, right?

To be clear - I still don't see a need for writing code in this style. If I was intent on writing obfuscated and hard to maintain code, designed to frustrate future maintenance developers, this is exactly what I'd do.

That's OK. When it comes to programming styles and idioms, different developers often have different opinions on which style is easier or more difficult to read and maintain. For instance some developers swear by more strict or pure functional programming styles over an object oriented approach, while others think functional programming can be difficult to read. Some mix and match both styles where appropriate. I think it's the same with imperative vs declarative. One of the benefits to using a programming language over a markup language is the flexibility to choose which style is appropriate or to blend both styles in a way that makes sense to you.

As for me personally, I'm coming from doing a lot of work with markup languages - mostly UI layouts on Android, WPF, Xamarin.Forms, and the web with HTML. It works well enough, but after seeing what's possible with frameworks like React and Flutter, I actually think the flexibility of using a programming language is a net positive in terms of benefits over a markup language.

[gulshan]

Kotlin is really nice with its it keyword and apply, also, run, with and let functions for all types of values/objects. Combined with its null checking, it let the devs produce concise and readable clean code.

[adamped]

@gulshan - could you please comment with an example on how you might think this would look in C#. I'm still interested in cascading expressions, but still some discussion to be had on possible best approaches :)

[gulshan]

@adamped I really don't know how the Kotlin constructs can be translated into C#. Kotlin has several different constructs, and they altogether makes it cleaner in my opinion. I want to mention some of them-

• it keyword to access the argument of a single-parameter lambda. Proposal: Shorthand for simple expression lambdas #91 has a similar proposal.
• Extension functions in Kotlin access the object being extended as this without the identifier. And this this keyword can be omitted in the definition. In C# the identifier is used in extension methods.
• In Kotlin, if the last parameter is a lambda, it can be written outside the arguments parenthesis like- do(1, {…}) can be written as do(1){…}.

With all this, Kotlin can have something like (Kotlin don't use new for constructor calls)-

val entry = Entry().apply{
    Text = "Something"
    Color = Color.Black
    TextChanged += Entry_TextChanged
}

Which will be in single line-

val entry = Entry().apply{ Text = "Something"; Color = Color.Black; TextChanged += Entry_TextChanged }

More Kotlin details can be seen at- https://kotlinexpertise.com/coping-with-kotlins-scope-functions/

The closest I think we can have in C# is with #91 -

var entry = new Entry().Apply({
    @.Text = "Something";
    @.Color = Color.Black;
    @.TextChanged += Entry_TextChanged;
});

But this still doesn't feel as clean as Kotlin.

[YairHalberstadt]

@gulshan

The example given would use a lambda where it is completely unnecessary, just to provide some syntax sugar.

Given the overhead of a lambda (every lambda creates at least one allocation, and a function call at minimum), I don't think it's sensible using lambdas purely as syntactic sugar.

[gulshan]

How Kotlin handles it- https://kotlinlang.org/docs/reference/inline-functions.html

[lightway82]

Kotlin used lambda with receiver with inlining. Lambda with receiver is a nice feature for creating powerful construction, like : with, also, run, apply, use , etc( see kotlin specification).