Proposal for Enhancing the Delegate Syntax in C#

[samuelyounge]

Proposal Summary:
Transform the delegate keyword to prefix variable declarations, indicating that the variable is a reference to a function or method. This would allow for a more natural and comprehensible syntax while preserving all existing benefits of delegates and Func constructs.

Example Syntax:

C#

private int delegate<int, string> MyMethodDelegate = (input1, input2) => 
{
    int myReturnValue;
    do 
    {
        var x = DoSomeWork(input1);
        myReturnValue = x + DoSomeMoreWork(input2);
    } 
    while (myReturnValue < 100);
    
    return myReturnValue;
};

Benefits:

Improved Readability: Aligns with standard C# variable declaration syntax, making it more intuitive.
Enhanced Flexibility: Allows both lambda expressions and full method declarations.
Consistent Syntax: Reduces the need for uncommon syntax styles currently used by delegate types.

This enhancement would streamline the use of high-order functions in C#, making the language more powerful and user-friendly.

Thank you for considering this proposal. I believe it could significantly improve the developer experience with delegates in C#.

May you walk with God always,
Sam

[colejohnson66]

I personally would also like to see unification between function pointers (delegate*) and MulticastDelegate derived types. If I could wave my magic wand and make "C#++", that’s one thing I’d do. Because right now, despite having the same signature, Func<T, bool> and Predicate<T> are not the same type.

Sadly, the work involved to do this with C# now is probably not worth it.

[timcassell]

I think rather than new syntax on top of existing delegates, this would play nicely with new struct delegates. #7785 (this is also what I was imagining in my alternative section). I'm not sure if this is do-able in only C# compiler, and would probably need to rely on the runtime implementing the delegate types, so that delegate from assembly A matches delegate with the same signature from assembly B.

[timcassell]

Part of the problem though is that it's not could enforce but must enforce. A struct delegate becomes a type that every language has to agree how to use. It is also viral because any type that has a member that is a struct delegate, must also be used with Atomic<T> (at least when assigning that is the struct delegate.

If the runtime enforces atomic r/w of struct delegates, it stands to reason it can enforce atomic r/w of those fields of a struct that is being copied. A struct containing a struct delegate being copied will read each struct delegate field atomically.

That even starts asking questions like "can this be used in generics?"

I don't see why not? The runtime already special-cases struct generics, this would just be an extra-special-case.

Take a step back and it has a lot of similarities to ref struct. Yes it doesn't have the fundamental limitation that it can't be in the heap, but the nature of the atomic assignments (and atomic reads) put many of the same constraints in place.

Well, it's certainly not impossible, but I do see the large amount of work it would take to make it work. Which probably means it will never happen...

Those can't capture ref struct members.

Yes they can, with the new allows ref struct anti-constraint.

[jaredpar]

I don't see why not? The runtime already special-cases struct generics, this would just be an extra-special-case.

The runtime sometimes special cases struct generics. There are versions of the runtime that do not.

Yes they can, with the new allows ref struct anti-constraint.

That only works if

1. The closure type is a ref struct
2. State is explicitly passed and is a ref struct

Either case, at that point they're fundamentally not different from a ref struct delegate.

[timcassell]

I don't see why not? The runtime already special-cases struct generics, this would just be an extra-special-case.

The runtime sometimes special cases struct generics. There are versions of the runtime that do not.

Like NativeAOT? I'm sure there's a way to make it work, but I'm not going to waste brain-power on that at this point.

Yes they can, with the new allows ref struct anti-constraint.

That only works if

1. The closure type is a ref struct
2. State is explicitly passed and is a ref struct

Of course the display type would need to be a ref struct to capture ref struct values. Everything would be in the display struct, you would not need to explicitly pass state. I believe this was all explained in the functional interfaces proposal.

Either case, at that point they're fundamentally not different from a ref struct delegate.

They may be functionally equivalent, but they are fundamentally different. Functional interfaces can capture state without allocating, while delegates must allocate a display class, whether it's a ref struct or otherwise. And delegates cannot capture ref struct members at all, even if the delegate itself is ref struct.

[jaredpar]

Functional interfaces can capture state without allocating,

To a degree. Essentially only when used as a constrained type parameter. When used as the stated interface type then they will always allocate.

[jaredpar]

Functional interface are inline with one of the ways that's we've been thinking about value delegates. Probably more accurate to say allocation free delegates than value delegates.

C# 13 adds building blocks around ref struct we knew were necessary to solving this problem. Now that they're in place we can more seriously look at the solutions.

[KennethHoff]

If we're going to change the delegate syntax, then I think following the way it's done in Typescript is a much better proposal. I know I've seen such a proposal before, but I couldn't find it looking it up now, but the gist of it is this:

// Old syntax
Func<int, int, bool>

// New syntax
(int, int) => bool

[timcassell]

I like it. That looks like it would also nicely work with named arguments (erased similar to ValueTuple element names).

(int index, int count) => bool

[jaredpar]

private int delegate<int, string> MyMethodDelegate ...

Your proposal does not specify how this signature would be emitted into IL. Under the hood delegates are nominal types, not structural. That means a concrete type must be emitted for MyMethodDelegate in IL. What type would be used here? If the answer is variations of Func and Action then what happens when they can't be used? For example, ref int delegate<int, string> can't be represented through standard Func signatures.

[alrz]

When extensions come around I think the compiler could implement adapters for those passed across assemblies, I believe that's something extensions will enable eventually?

[timcassell]

When extensions come around I think the compiler could implement adapters for those passed across assemblies, I believe that's something extensions will enable eventually?

Extensions won't magically enable identity conversion between delegate types. The runtime checks the delegate's type when delegates are combined. The minimum that would be required is to allocate a delegate of the other type.

[alrz]

I didn't claim this works magically, I said "the compiler could implement adapters for those passed across assemblies", basically building delegatetypes on top of extensions where delegate<...> syntax is emitted as an interface that could be implemented externally. This doesn't need dedicated runtime support for structural delegates, rather reusing whatever codegen that extensions will compile to.

[jaredpar]

The minimum that would be required is to allocate a delegate of the other type.

Correct and that creates a number of problems. The first is a silent allocation which is generally not great. The other problem is that it breaks identity with the original delegate. That means you could easily get into situations where you subtly break behavior that relies on identity: lock, event handler add / remove, etc ...

[timcassell]

That would just hide performance reductions behind nicer syntax, which I am not a fan of.

[kyoyama-kazusa]

#8004