Adding the static-delegate proposal. #126

tannergooding · 2017-02-16T05:16:58Z

This is the official proposal for #80, which @jaredpar has agreed to champion.

tannergooding · 2017-02-16T05:19:56Z

proposals/static-delegates.md

+## Alternatives
+[alternatives]: #alternatives
+
+TBD


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.

tannergooding · 2017-02-16T05:21:02Z

proposals/static-delegates.md

+## Drawbacks
+[drawbacks]: #drawbacks
+
+TBD


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 😄

tannergooding · 2017-02-16T05:24:18Z

proposals/static-delegates.md

+
+That is to say, it is internally represented by a struct that has a single member of type `IntPtr` (such a struct is blittable and does not incur any heap allocations). The member contains the address of the function that is to be the callback. Additionally, the type declares a method matching the method signature of the callback.
+
+The value of the static delegate can only be bound to a static method that matches the signature of the callback.


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.

alrz · 2017-02-16T11:49:19Z

So we will have the whole set of new delegate types StaticAction<..> etc?

tannergooding · 2017-02-16T15:21:47Z

@alrz, I believe so. Although that would be part of a coordinated effort with the framework team (for betterness), rather than part of the proposed language spec/

tannergooding · 2017-02-16T15:24:34Z

proposals/static-delegates.md

+## Drawbacks
+[drawbacks]: #drawbacks
+
+Static Delegates would not work with existing APIs that use regular delegates (one would need to wrap said static delegate in a regular delegate of the same signature).


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.

jaredpar · 2017-02-16T15:36:54Z

proposals/static-delegates.md

+* [ ] Specification: Not Started
+
+## Summary
+[summary]: #summary


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).

jaredpar · 2017-02-16T15:37:53Z

proposals/static-delegates.md

+The declaration would get translated into an internal representation by the compiler that is similar to the following
+
+```C#
+struct <name>


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.

jaredpar · 2017-02-16T15:38:47Z

proposals/static-delegates.md

+{
+    IntPtr pFunction;
+
+    static int Func();


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.

jaredpar · 2017-02-16T15:39:57Z

proposals/static-delegates.md

+
+Invocation of the callback would be implemented by the `calli` instruction.
+
+


double blank line.

jaredpar · 2017-02-16T15:40:53Z

proposals/static-delegates.md

+## Drawbacks
+[drawbacks]: #drawbacks
+
+Static Delegates would not work with existing APIs that use regular delegates (one would need to wrap said static delegate in a regular delegate of the same signature).


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

alrz · 2017-02-16T15:54:53Z

proposals/static-delegates.md

+One would declare a static delegate via the following:
+
+```C#
+static delegate int Func()


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.

tannergooding · 2017-02-16T21:34:54Z

@jaredpar, I believe (since you are championing this) the proposal needs your explicit approval before it can be merged. Let me know if you think any further modifications or clarifications are necessary.

jaredpar · 2017-02-16T23:55:11Z

CC @dotnet/csharplangdesign

jaredpar · 2017-02-16T23:58:28Z

@tannergooding one other aspect I think we need to make note of somewhere: this will require some run time changes in the following areas:

Verification: the verifier has special knowledge of the manner in which normal delegates are created. Essentially to ensure the method token being passed to the constructor is indeed a valid signature. This same process needs to be applied to static delegates.
Code unloading: for environments where code unloading is supported (AppDomains for example) there likely needs to be special knowledge of static delegates. They represent a new type which can essentially prevent DLLs from being unloaded.

I'm unsure if the proposal needs to go that deep here. Will defer to @gafter if that is appropriate or not here.

tannergooding · 2017-02-17T00:39:26Z

@jaredpar is that actually the case though?

For any calli instruction, the following correctness & verification exists:

In order to assign the value of a static delegate, one would additionally need to either have the declaration come from native code (unverifiable) or one would need to use the ldftn instruction, which has the following correctness & verification:

My understanding of that is that, for verifiable code, the verifier should already be able to handle combinations of ldftn and calli, or is that not the case?

tannergooding · 2017-03-16T21:16:55Z

@jaredpar, @gafter. Is there anything else that needs to be figured out here to get the proposal merged (it can certainly be updated further, post-merge, if need be)?

gafter · 2017-03-16T21:35:14Z

I think this is fine to merge (@jaredpar). We can refine it later as needed.

tannergooding · 2017-03-21T00:02:18Z

#302

Adding the static-delegate proposal.

d367272

tannergooding commented Feb 16, 2017

View reviewed changes

Adding a couple of drawbacks to the static-delegates proposal.

6b8bd95

tannergooding commented Feb 16, 2017

View reviewed changes

jaredpar reviewed Feb 16, 2017

View reviewed changes

alrz reviewed Feb 16, 2017

View reviewed changes

Clarifying on some points in the static-delegates proposal.

e23c9e0

gafter assigned jaredpar Feb 27, 2017

tannergooding mentioned this pull request Mar 3, 2017

Initial blittable proposal #206

Merged

jaredpar approved these changes Mar 16, 2017

View reviewed changes

tannergooding merged commit c5de26f into dotnet:master Mar 16, 2017

gafter mentioned this pull request Apr 23, 2017

Proposal: PrimitiveValueType and Generic Pointers #492

Closed


		That is to say, it is internally represented by a struct that has a single member of type `IntPtr` (such a struct is blittable and does not incur any heap allocations). The member contains the address of the function that is to be the callback. Additionally, the type declares a method matching the method signature of the callback.

		The value of the static delegate can only be bound to a static method that matches the signature of the callback.


		Invocation of the callback would be implemented by the `calli` instruction.

Adding the static-delegate proposal. #126

Adding the static-delegate proposal. #126

Conversation

tannergooding commented Feb 16, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tannergooding Feb 16, 2017 • edited Loading

Choose a reason for hiding this comment

alrz commented Feb 16, 2017 • edited Loading

tannergooding commented Feb 16, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alrz Feb 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tannergooding commented Feb 16, 2017

jaredpar commented Feb 16, 2017

jaredpar commented Feb 16, 2017

tannergooding commented Feb 17, 2017

tannergooding commented Mar 16, 2017

gafter commented Mar 16, 2017

tannergooding commented Mar 21, 2017

tannergooding Feb 16, 2017 •

edited

Loading

alrz commented Feb 16, 2017 •

edited

Loading

alrz Feb 16, 2017 •

edited

Loading