inline or sync keyword for function callback

[Thaina]

async callback is powerful feature. But sometimes it overkill to enforce all callback pass in function

First limitation is callback function cannot using ref parameter unless we copy it

And Sometimes function is just iterator or little extension method that could and should be inlined both callback and the function itself

So I think we should have inline or sync keyword at least at function parameter. And the function written at callback could access ref parameter

inline void ForEach(this IEnumerable<T> items,inline Func<T,bool> callBack)
{
    foreach(var item in items)
         callBack(item);
}

void Main(ref LargeStruct ls)
{
    ["Setting0","Setting1","Setting2"].ForEach(inline (key) {
         ls.Set(key); // normally cannot access ref struct here
    });
}

[HaloFour]

You use the example of inline with a lambda passed to a BCL method, but that's not something that can be inlined because ForEach expects a delegate. That delegate must be a separate method. I'm not sure what the compiler could do to allow accessing that ref other than making a local copy anyway, which doesn't have the same semantics as actually referencing a ref.

[Thaina]

@HaloFour That's why I propose inline syntax. You may see delegate at my ForEach but when it have inline in front it would not be a delegate. Instead it reduce the delegate into just a contract of what need to be passed in

Like generic constraint by interface that you don't cast object passed in into that interface. It just define contract that the object passed in must be that interface, then it actually generate function for that object

In other word. This maybe just a syntax that would transpile syntax tree to inline. And that would make you able to call ref in lambda

[HaloFour]

@Thaina

You may see delegate at my ForEach but when it have inline in front it would not be a delegate.

That's not possible, the BCL method requires a delegate. There's nothing else that the C# compiler could pass to it that would satisfy that requirement.

In other word. This maybe just a syntax that would transpile syntax tree to inline. And that would make you able to call ref in lambda

It couldn't transpile the call to ForEach, and that method still requires a delegate, so the C# compiler still has no choice but to allocate a delegate to a method representing that lambda. At best it could transpile direct calls to a lambda, but you already have local functions which allow you to call ref parameters directly.

Like generic constraint by interface that you don't cast object passed in into that interface. It just define contract that the object passed in must be that interface, then it actually generate function for that object

That's not what the C# compiler does at all. The compiler just dispatches the calls to the required members of that interface to the generic type, which is guaranteed to succeed by the CLR enforcing the generic type constraint. There are no other generated functions.

[svick]

I think this could work only if the C# compiler know exactly what ForEach() does and has a guarantee that it won't change.

But neither is true: the C# compiler often compiles against reference assemblies, which don't contain any code. And even if you compile against assemblies with code, the user is free to use different implementation when running the code.

[GSPP]

This should be a JIT feature. There could be a heuristic that makes the JIT inline away the entire iterator machinery, stack allocate all temporary objects and derive the exact types and delegate targets for all relevant objects in order to devirtualize everything.

There's no reason this could not be as fast as an optimal hand-written loop.

[svick]

@GSPP I agree that's the best way to get something similar. But it won't help with the motivating example, which was about accessing a ref parameter from the lambda.

[Thaina]

@HaloFour I think you could try by create a generic class like this

class TT<T>
{
    static T[] Array = new T[10];
}

static void Main()
{
    if(!TT<int>.Array.Equals(TT<long>.Array))
        throw new Exception("Generic generate new class");
}

Generic is not just dispatch the call. If it is value type it would pass that object without boxing to interface. I am quite sure that it generate new things map to each type

I would have inline to interrupt syntax tree generation so that when inline stay in front of delegate parameter. it would not convert lambda into delegate but try to modify syntax tree to be inline

[yume-chan]

I don't understand why inline your lambda into ForEach helps it to access the ref parameter. Maybe you want to inline the ForEach method into the call site so it all become one method? But how can the compiler do it without the source code or IL code of the ForEach method? What will happen if the implementation of ForEach is changed in the future?

We all know generic types will be generated for every type parameter usage, but it's not the compiler's job, at least when targeting Desktop CLR. The actual types are generated at runtime, by the JIT compiler. The JIT compiler do can inline ForEach into your method, but it will cause a big effect on memory usage and performance, as opposed of generic type case.

[Thaina]

@CnSimonChan The problem that we can't use ref arguments in callback function is, you may
know, because callback function is not guaranteed to call in the same function stack

So if we could have a feature to enforce immediately call then it possible to access reference arguments

And if modified current implementation can cause problem. Well, we could just create new library to support it. namespace System.Linq.Sync maybe

And to compile program to work as we want is compiler's jobs. It is programmer jobs to do optimization first hand before JIT. And I request that programmer should have access to the tools that can order JIT to do work as we wish it to be like