Function pointer design #282
Conversation
steveharter
requested review from
jkotas,
MichalStrehovsky,
AaronRobinsonMSFT and
buyaa-n
| + Type functionPointerType) | ||
| } | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Reflection.Emit will need some work to deal with function pointers correctly beyond the new EmitCalli overloads.
Consider this example that tries to emit a call to a method that takes function pointer https://gist.github.com/jkotas/79c7c673b7d892f41f6be5f16d380aed . It does not work today. MethodInfo returns IntPtr instead of actual type, Reflection.Emit encodes method reference with a wrong signature, and we get MissingMethodException at runtime.
The problem is that this example cannot work even once this proposal is implemented. The example contains a function pointer with modreqs, but Reflection.Emit has no way to see the modreqs. It means that it is still going to emit reference with a wrong signature and we will get MissingMethodException at runtime.
This suggests that we cannot actually omit function pointer modopts/modreqs in runtime reflection object model if we want to have full support for function pointers in Reflection.Emit.
There was a problem hiding this comment.
Wouldn't we run into the same problem if we wrap access to a get; init; setter like that? I think the problem is really that the runtime reflection system was not designed to introspect modifiers. It was designed to ignore them.
Edit: maybe not. We can still read that one. But we still cannot e.g. reflection-invoke C++/CLI methods with pointers to const for the same reason.
There was a problem hiding this comment.
We should be able to emit init-only properties today. (We had bugs reported in it that got fixed by #40587.)
reflection-invoke C++/CLI methods with pointers to const for the same reason.
Yes, it is similar to #282 (comment) .
| ``` | ||
|
|
||
| # Breaking changes | ||
| The breaking change is: **`typeof(delegate*<...>)` and `Type.GetType()` will return a `Type` instance instead of `IntPtr`** |
There was a problem hiding this comment.
Observation: This breaking change is not actually strictly required to make the function pointers inspectable by reflection. We can keep the runtime current behavior and tell people to use signature types to gather any function pointer details.
(I am not trying to oppose the breaking change. Just sharing an observation.)
There was a problem hiding this comment.
Interesting; but I would say doing that goes against the goal of "correcting" the Type system.
Design that should be approved before implementation is continued and before we update API issues.