Update function pointer proposal with LDM changes #2923
Conversation
333fred
force-pushed
the
new-func-ptr-syntax
branch
from
be0e31a
to
e2f485c
Compare
|
@gafter @MadsTorgersen @stephentoub @jkotas, did you have any comments? |
| work though as a `mod_req` cannot bind to a `TypeSpec` and hence cannot target generic instantiations. | ||
|
|
||
| ### Named function pointers | ||
|
|
||
| The function pointer syntax can be cumbersome, particularly in complex cases like nested function pointers. Rather than |
There was a problem hiding this comment.
The [](start = 0, length = 3)
Please say something to make it clear that this is an alternative to, and not part of, the spec. #Resolved
There was a problem hiding this comment.
This is in a bigger section titled Considerations, with a bunch of different future proposals.
In reply to: 344939001 [](ancestors = 344939001)
|
@gafter for your comments, I agree that we need to nail down the concepts of conversion for method groups in function pointers, but I think that's out of scope for this PR. I'm just updating the syntax here, so I'm going to resolve your comments and come back to them at a later time. |
| - A `func*` parameter cannot be marked as `params` | ||
| - A `func*` type has all of the restrictions of a normal pointer type. | ||
|
|
||
| - Custom attributes cannot be applied to a `delegate*` or any of its elements. |
There was a problem hiding this comment.
Custom attributes can't be applied today but we will likely want the ability to expose them in the future (to support GCSuppressTransition, other calling convention designations, etc).
Presumably, the compiler is currently planning on emitting these types directly as FNPTR type signatures. However, the runtime doesn't currently have any way to attach attributes to such type signatures.
Has this been taken into consideration since that would make it a breaking change to go from the inline function pointer syntax (the only thing available today) to change to some syntax that allows attributes?
There was a problem hiding this comment.
Custom attributes can't be applied today but we will likely want the ability to expose them in the future
Is there a design stating how such support would be implemented in the runtime?
Has this been taken into consideration since that would make it a breaking change to go from the inline function pointer syntax (the only thing available today) to change to some syntax that allows attributes?
No it hasn't because the underlying runtime support for this does not exist and would likely require changes to calli or the method in which the signature is provided to calli. Can't really take it into consideration if we don't know how the feature would be implemented in the runtime.
There was a problem hiding this comment.
Asked someone from the runtime team to comment on the relevant issue: dotnet/roslyn#39865 (comment)
|
Filed dotnet/roslyn#39865 to track the open questions raised in this pr. |
No description provided.