Developers using Reflection should be able to use pointers and function pointers

[steveharter]

Treatment of pointers in general is hit-and-miss especially with the newer function pointer (delegate*) feature.

Currently with function pointers, an IntPtr or fnptr* types are returned, so it is not possible today to distinguish between function pointers and other uses of IntPtr, for example. It is also not possible to determine the parameter types, return type or the calling convention.

• Representation of function pointer types in the reflection stack
  • See API proposal based somewhat off of original draft Gist proposal
• Runtime: Support for reflection-invoking methods that take pointers by reference
• Type validation holes when using Reflection to invoke a method with a void* parameter

[BreyerW]

What about ref in general? Eg ref prop ref returning methods etc? This part historically was half assed since support for it was added relatively recently in languages (several years at this point). Is this on the table?

[steveharter]

What about ref in general?

Any common use case that is not supported is being considered. @BreyerW can you share an example so this is properly captured here? Thanks

[BreyerW]

@steveharter im not expert on reflection but i remember having trouble with ref return methods when generating dynamic methods it simply fails (dont remember exact exception since its year ago by now). Although theres workaround by defining entire assembly then generating ref return method inside that assembly but it isnt easy to discover i myself found that solution on accident in stackoverflow thread. Ref prop probably has similar issue since its method behind the scene.

Also frontline reflection API (or in other words most easily discoverable API) like GetValue dont have ref alternatives at all. I think even @jkotas or someone from net core team made a thread about this API type few years ago when dotnet/runtime was dotnet/corefx but you never fully committed resources to this and as such they never materialized

Last gripe is in System.Linq.Expression. this namespace is often bugged in presence of new uses of ref eg when trying to generate assignment to ref prop it fails because ref prop is defined as CanWrite=false despite being obviously wrong. Then again you killed this namespace's future so i guess this particular case is of no interest to you