C# does not currently provide any mechanism to expose the calli instruction. So, I believe the only alternative would be to implement the required functionality in pure IL.

Yep.

I can't really think of any drawbacks here. The design described above should be completely verifiable and relatively simple to implement.

I thought of some drawbacks last night, mostly due to the comment by @alrz 😄

For better interop with unmanaged code, it might be desirable to allow assigning the value of a static delegate to that of an IntPtr (in an unsafe context only given that it is unverifiable).

However, given that the static delegate type is itself blittable, the only scenario this would improve is if you had an unmanaged function that returned a void* instead of a typed function pointer (I can't think of any APIs off the top of my head that do this and I wouldn't think this would be common practice anyways).

As such, I left that off the proposal.

It is probably worth noting that System.Delegate is represented (internally) as a set of object and IntPtr fields (http://source.dot.net/#System.Private.CoreLib/src/System/Delegate.cs). It may be possible to provide a one way conversion from static delegate to System.Delegate (this could possibly be bidirectional if we can validate the Delegate conforms to the requirements of a static delegate).

This incompatibility could be addressed though. The language could allow an implicit conversion from any static delegate to a normal delegate with compatible signatures.

Yes, which is why I called it out here. I will add a note to the proposal indicating that we could workaround this.

Note added.

What is this mark down trick doing?

It allows you to link to the sub-section of the document (this is based on the proposal-template.md).

The <name> here should be Func.

I put a placeholder here because I think just Func isn't enough, it would need to be a non-user constructable identifier as we do with other backing structs. For example, with fixed size buffers we do <name>e__FixedBuffer (the < and > are not placeholders but part of the actual identifier), so in this case we would do something like <Func>e__StaticDelegate (or something similar, I would imagine).

Changed the placeholder and provided a text explanation/example.

The name here should be a standard name used across all static function types. That way the compiler knows what name to look for when determining the signature.

Not sure if that's going too far or not for the language spec though as it's a bit of implementation detail of the compiler.

I'm not sure either. @MadsTorgersen or @gafter, how should we represent placeholder data like this?

I updated this to be WellKnownCompilerName for the time being and added a text description indicating as such.

double blank line.

Removed.

This incompatibility could be addressed though. The language could allow an implicit conversion from any static delegate to a normal delegate with compatible signatures.

Bikeshed: static delegate could be confusing such that it can only refer to static members (in fact I'm already confused and not sure if that's the case), I'd suggest struct delegate though that's probably your last concern. :)

@alrz, static delegates can only refer to static methods. This is because delegates which refer to instance method also require you to carry a reference to the this object and that makes them inherently non-blittable.

Also, maybe value delegate to better match the naming convention for other types we have done similar things (ValueTuple, ValueTask, etc...), although I don't much care what the name is, provided I can use the feature.

I prefer static delegate over value delegate.

The Value pattern is used today for types which are being made a struct type. The Value prefix is given to distinguish them from the well know class types. If there were a well known base type for this feature then I agree that calling it ValueDelegate would make sense. That's not the case though here, there is in fact no common base type to refer to.

In this case it's a delegate that can only refer to static members. There are existing examples in the language of using static to modify existing types such that it can only contain static content: static class. The static delegate notation is just feeding into this existing usage.

What about open delegates? Delegate.CreateDelegate would probably not work with this. Will there an API to create an open static delegate that directly points to a member of the input parameter?

I'm confident that this document correctly reflects the current (very preliminary) state of the proposal. We can discuss possible changes to it in the linked issue.