Proposal:Lambda expression with separated closure

[RamType0]

Backgrounds

There are many API in .NET which takes Action action or Func<TResult> func as argument.
such as TaskFactory.StartsNew,ThreadPool.QueueUserWorkItem.
Most of these also have overloads which takes Action<object>action,object state or Func<object,TResult> func,object state.
These overloads are useful to reduce delegate allocation.
But currently,these overloads are hard to use.Because of missing lambda expression syntax support.

Proposed Syntax

(closure object state, Action<object> action) = (state)=>{}

[svick]

I don't understand what is the proposed syntax supposed to achieve. Could you describe that, ideally including an example of how it would be used?

[HaloFour]

But currently,these overloads are hard to use.Because of missing lambda expression syntax support.

Why do you feel that these overloads are hard to use? What is this "missing lambda expression syntax support" and how does it change anything? Please provide some code examples of where the existing syntax is a problem and how/why whatever it is that you're proposing would change any of that.

[RamType0]

Why do you feel that these overloads are hard to use? What is this "missing lambda expression syntax support" and how does it change anything? Please provide some code examples of where the existing syntax is a problem and how/why whatever it is that you're proposing would change any of that.

When I use TaskFactory.StartNew with Action action overload
We could use this with following syntax.

void Sample(int parameter)
{
   Task.Factory.StartNew(()=>
{
   DoSomeStuffWithParameter(parameter);
});
}

Every time we call this method,one closure (it captures parameter) and one delegate is allocated.

When I want to do same thing with Action<object> action,object state overloads and also want to get advantages of performance,syntax should be like following.

class Closure
{
   internal int parameter;
}

void Sample(int parameter)
{
   Task.Factory.StartNew((state)=>
   {
      var closure = (Closure)state;
   DoSomeStuffWithParameter(closure.parameter);
   },new Closure(){parameter = parameter});
}

With this code,one closure has been created each time we call this method,but allocates delegate only once when we call this method at first.

We must manually look up which parameter should be captured,and need to define closure explicitly.If looking up was not correct,this causes one more closure and delegate creation each time we call this method,and it would rather make slower performance.

With proposed syntax,This should be done with following syntax.

void Sample(int parameter)
{
   (closure object state,Action<object> action) = (state)=>
   {
      DoSomeStuffWithParameter(parameter);
    }
   Task.Factory.StartNew(action,state);
   

Moreover, There are widely discussed syntax which provided only for avoid allocation from lambda expression.

I want this functionality,but I don't obsess with this syntax.

[HaloFour]

I see, so what you want to see is for the allocated closure to be passed along as the state parameter automatically? I don't see how that avoids an allocation, it just moves it. You don't incur an allocation for the lambda, but you will incur an allocation for that "state" that you're passing.

IMO that API pattern is also a remnant from an earlier time before closures were common, I don't think you find that terribly often anymore.

[RamType0]

I see, so what you want to see is for the allocated closure to be passed along as the state parameter automatically? I don't see how that avoids an allocation, it just moves it. You don't incur an allocation for the lambda, but you will incur an allocation for that "state" that you're passing.

Yes,we still need to create closure each time we call it,and I explicitly mentioned that.

With this code,one closure has been created each time we call this method,but allocates delegate only once when we call this method at first.

I also mentioned about it advantages.

IMO that API pattern is also a remnant from an earlier time before closures were common, I don't think you find that terribly often anymore.

I think you are partialy right.Action<object>,object stateoverload is not present in Task.Run.
But we could see Action<object>,object state in very modern API.
It is IValueTaskSource.OnCompleted.

Yeah,it seems like little bit ugry,but fast.

[HaloFour]

Seems like a lot of syntax for a feature that saves at most one allocation on fairly uncommon APIs.

IMO in those rare situations you'd get more mileage out of a helper method that allowed you to pass a generic type as the state so that you can specify an anonymous class as the closure:

using System;
using System.Threading.Tasks;

public class C {
    public void M(int parameter) {
        
        var task = StartNewTask(new { parameter },
                state => DoSomethingWithParameter(state.parameter));
    }
    
    public void DoSomethingWithParameter(int parameter) { }
    
    private Task StartNewTask<S>(S state, Action<S> action) {
        return Task.Factory.StartNew(s => action((S)s), state);
    }
    
    private Task<T> StartNewTask<S, T>(S state, Func<S, T> action) {
        return Task.Factory.StartNew(s => action((S)s), state);
    }
}

[RamType0]

Seems like a lot of syntax for a feature

Such a code generation is already done with asyncmethods.(Obliviously,it is used for OnComplete.)

that saves at most one allocation

ValueTask just have possibility to reduce just one allocation and it also have many disadvantages (e.g. awaiting multiple times could cause undefined behaviour) ,but it was widely approved.
This feature always reduces one allocation.

on fairly uncommon APIs.

Really?
Let me show you part of these...

• CancellationToken.Register(Action<Object>, Object)

• ThreadPool.QueueUserWorkItem(WaitCallback, Object)

• System.Threading.Timer(TimerCallback, Object, Int32, Int32)

• ThreadPool.RegisterWaitForSingleObject(WaitHandle, WaitOrTimerCallback, Object, UInt32, Boolean)

• SynchronizationContext.Post(SendOrPostCallback, Object)

• SynchronizationContext.Send(SendOrPostCallback, Object)

• ExecutionContext.Run(ExecutionContext, ContextCallback, Object)

• TaskFactory.StartNew(Action<Object>, Object)

• Task.ContinueWith(Action<Task,Object>, Object)

using System;
using System.Threading.Tasks;

public class C {
    public void M(int parameter) {
        
        var task = StartNewTask(new { parameter },
                state => DoSomethingWithParameter(state.parameter));
    }
    
    public void DoSomethingWithParameter(int parameter) { }
    
    private Task StartNewTask<S>(S state, Action<S> action) {
        return Task.Factory.StartNew(s => action((S)s), state);
    }
    
    private Task<T> StartNewTask<S, T>(S state, Func<S, T> action) {
        return Task.Factory.StartNew(s => action((S)s), state);
    }
}

Looks like really good and it solves any problems I previously proposed,but it causes one more virtual call and one more function pointer call.

[HaloFour]

Such a code generation is already done with async methods.

The return on investment for async methods has been massive and transformative for C# and a number of other programming languages. This proposal won't have remotely the same degree of impact.

ValueTask just have possibility to reduce just one allocation and it also have many disadvantages (e.g. awaiting multiple times could cause undefined behaviour) ,but it was widely approved.
This feature always reduces one allocation.

ValueTask isn't a C# feature, it's a part of the BCL library. The C# feature that enabled ValueTask was to allow for custom types to be returned from async methods supported by task-like builders.

Without that task-like feature and ValueTask there was no way to use a zero-allocation task-like type in hot paths which made writing asynchronous code very awkward (it's already viral). Avoiding this one allocation for particular API pattern is already easy to do and doesn't need language features.

Really?
Let me show you part of these...

9 APIs aren't a lot. It's probably a little more than a dozen in total. That's nothing. And these aren't APIs that developers commonly interact with directly. TPL and async/await has made pretty much all of the APIs listed obsolete.

but it causes one more virtual call and one more function pointer call.

Those helper methods aren't virtual, and they can be made static. They're simple enough to likely be inlined by JIT.

[RamType0]

Such a code generation is already done with async methods.

The return on investment for async methods has been massive and transformative for C# and a number of other programming languages. This proposal won't have remotely the same degree of impact.

I mean that it is already mostly implemented, so we doesn't need to taking a cost so much about new code generation.

ValueTask just have possibility to reduce just one allocation and it also have many disadvantages (e.g. awaiting multiple times could cause undefined behaviour) ,but it was widely approved.
This feature always reduces one allocation.

ValueTask isn't a C# feature, it's a part of the BCL library. The C# feature that enabled ValueTask was to allow for custom types to be returned from async methods supported by task-like builders.

Perfectly separating features of C# and BCL library means "Any existing code is not a part of the C#".

Without that task-like feature and ValueTask there was no way to use a zero-allocation task-like type in hot paths which made writing asynchronous code very awkward (it's already viral).

ValueTask never reduces allocation of asynchronous path.it just reduces allocation when
"Asynchronous path could be expected,but today,we dont have it".
If we need to reduces allocation of really asynchronous path, the best (for allocation),but ugly solution is manually inlining every nested asyncmethod call.

Avoiding this one allocation for particular API pattern is already easy to do and doesn't need language features.

Really?
Let me show you part of these...

9 APIs aren't a lot. It's probably a little more than a dozen in total. That's nothing. And these aren't APIs that developers commonly interact with directly. TPL and async/await has made pretty much all of the APIs listed obsolete.

• ThreadPool.RegisterWaitForSingleObject(WaitHandle, WaitOrTimerCallback, Object, UInt32, Boolean)

We still need to use WaitHandle for waiting platform provided signals.
It is still mostly only way to awaiting it efficiently.

• System.Threading.Timer(TimerCallback, Object, Int32, Int32)

await Task.Delay() allocates Task every time we call it.

• CancellationToken.Register(Action<Object>, Object)

This API has been recently updated.

Maybe because it is still common.

but it causes one more virtual call and one more function pointer call.

Those helper methods aren't virtual, and they can be made static. They're simple enough to likely be inlined by JIT.

Your helper method itself is quite simple,and maybe inlined by JIT.
But with your helper method,we have one more nested invocation of delegate.
invocating delegate at least costs one virtual call,and function pointer call.
I have never seen the virtual call and function pointer call through delegate has been terminated by JIT.

[svick]

@RamType-0

ValueTask never reduces allocation of asynchronous path.

It does, thanks to IValueTaskSource. You might want to read this article which explains the details.

[RamType0]

@RamType-0

ValueTask never reduces allocation of asynchronous path.

It does, thanks to IValueTaskSource. You might want to read this article which explains the details.

Yeah,I know that,and I am using ManualResetValueTaskSourceCore<T> and ThreadPool.RegisterWaitForSingleObject together to await platform provided signal asynchronously and efficiently.
And we could also get advantages of this feature with async IAsyncEnumerable<T>.(Only one instance have been created for each continuous iteration.Each MoveNextAsync never creates new instance.)
I said aboud "async" ValueTask.

[RamType0]

@svick
My previous description was not enough,
I want to say that "There is a case the feature which only potencially reduces only one allocation has been approved".
IValueTaskSource feature has not been included in ValueTask at first.but it was approved.

and also IMO,Adding IValueTaskSource feature was not expected at first.
Because IValueTaskSource feature caused breaking changes for ValueTask.
(Before adding IValueTaskSource feature to ValueTask,awaitng it multiple times was safe,and accessing Result property before it complete was also safe.)

[RamType0]

WIth this feature,we can widely reduces allocation by defining method which takes (object state,Action<object> action)(it is value tuple) for argument.

[RamType0]

I just find likely issues.
#1060

[SingleAccretion]

9 APIs aren't a lot

Adding one more:

• String.Create<TState>(int length, TState state, System.Buffers.SpanAction<char, TState> action)

[alrz]

The problem with this proposal is that you should specify the actual delegate type which is not identical to the one that is passed in.

Today, we have:

bool Any<T, TArg>(this ImmutableArray<T> array, Func<T, TArg, bool> predicate, TArg arg);
// manually pass intended captures
array.Any(static (item, t) => Use(item, t.a, t.b), (a, b))

Ideally we could rewrite that like this:

bool Any<T>(this ImmutableArray<T> array, closure Func<T, bool> predicate);
// capturing a, b but actually not;
// those are passed implicitly to a compiler-generated parameter
array.Any(static item => Use(item, a, b))

But that Func<T, bool> is no longer Func<T, bool>.

I imagine we can take advantage of a function type syntax here, (derived from func pointers)

// `closure` specifies that an additional parameter should be generated to pass captures
bool Any<T>(this ImmutableArray<T> array, closure delegate<T, bool> predicate);

array.Any(static item => Use(item, a, b))

But that still need the runtime support for delegate equivalence, since for a managed function type, we're going to generate managed delegates on the fly.

Unless we just use function pointers,

bool Any<T>(this ImmutableArray<T> array, closure delegate*<T, bool> predicate);

I think that is actually workable.

[333fred]

Remember, function pointers require unsafe due to assembly unloading.