Add conversions spec for function pointers #3263
Conversation
| - For each `ref`, `out`, or `in` parameter, the parameter type in `M` is the same as the corresponding parameter type in `F`. | ||
| - If the return type is by value (no `ref` or `ref readonly`), an identity, implicit reference, or implicit pointer conversion exists from the return type of `F` to the return type of `M`. | ||
| - If the return type is by reference (`ref` or `ref readonly`), the return type and `ref` modifiers of `F` are the same as the return type and `ref` modifiers of `M`. | ||
| - The calling convention of `M` is the same as the calling convention of `F`. |
There was a problem hiding this comment.
How you determine calling convention of M ? Is this going to take into account the NativeCallable attribute?
There was a problem hiding this comment.
Is this going to take into account the NativeCallable attribute?
I was planning on it doing so, yes, but I'm not sure if that's something that should be explicitly called out in our spec or if should be an implementation detail. @gafter for thoughts on that?
There was a problem hiding this comment.
It does not feel right to me to talk about calling convention in the spec, but not explain where it comes from.
There was a problem hiding this comment.
I agree that if the spec depends on a concept, it should define it. However, that can be left for a future refinement of this spec. Put it in an open issue?
There was a problem hiding this comment.
Added to the open issues list.
| - [_Existing conversions_](https://github.com/dotnet/csharplang/blob/master/spec/unsafe-code.md#pointer-conversions) | ||
| - From _funcptr\_type_ `F0` to another _funcptr\_type_ `F1`, provided all of the following are true: | ||
| - `F0` and `F1` have the same number of parameters, and each parameter `D0n` in `F0` has the same `ref`, `out`, or `in` modifiers as the corresponding parameter `D1n` in `F1`. | ||
| - For each value parameter (a parameter with no `ref`, `out`, or `in` modifier), an identity conversion, implicit reference conversion, or implicit pointer conversion exists from the parameter type in `F0` to the corresponding parameter type in `F1`. |
There was a problem hiding this comment.
implicit reference conversion, or implicit pointer conversion exists from the parameter type in
F0to the corresponding parameter type inF1. [](start = 109, length = 145)
Does runtime support this kind of mismatch natively, or will compiler have to generate a stub to make this work? #Closed
There was a problem hiding this comment.
Does runtime support this kind of mismatch natively, or will compiler have to generate a stub to make this work?
Natively. We don't even emit a cast for explicit conversions.
| - Only a `delegate*` with a managed calling convention can be the target of such a conversion. | ||
| In an unsafe context, a method `M` is compatible with a function pointer type `F` if all of the following are true: | ||
| - `M` and `F` have the same number of parameters, and each parameter in `D` has the same `ref`, `out`, or `in` modifiers as the corresponding parameter in `F`. | ||
| - For each value parameter (a parameter with no `ref`, `out`, or `in` modifier), an identity conversion, implicit reference conversion, or implicit pointer conversion exists from the parameter type in `M` to the corresponding parameter type in `F`. |
There was a problem hiding this comment.
implicit reference conversion, or implicit pointer conversion exists from the parameter type in
Mto the corresponding parameter type inF. [](start = 105, length = 143)
Same question here. #Closed
|
Do we want to/is it possible to support a conversion from a function pointer to a delegate? |
|
@AlekseyTs the runtime has an API for this today, |
I think I am talking about conversion in the opposite direction. I.e. passing a pointer to delegate's constructor. |
The runtime has a method going in the other direction as well, |
I am not sure why would we want to force a user to use this API and not have a benefit of type safety checks performed by a compiler. A delegate constructor takes a pointer (which we obtain for a method today) and, in function pointer case, we would have a pointer available. We also already have rules for method signature to delegate compatibility, which we can simply reuse. |
|
|
I added a note to the open issues to consider it. |
|
@AlekseyTs @jkotas did you have any more feedback? I'll address the typo when I'm confident that all the rest of the minor changes are accounted for. |
|
Looks fine to me otherwise. |
Co-Authored-By: Jan Kotas <[email protected]>
The summary for these specs are:
void*.