"Address of" operation on generic functions with type parameters

[Prabhuk]

Generic functions in Checked C accept type parameters. There are two function specifiers that can be used for this.

• _Itype_for_any (<COMMA_SEPARATED_TYPE_VARIABLES>)
• _For_any(<COMMA_SEPARATED_TYPE_VARIABLES>)

e.g.
_Itype_for_any(T1, T2) void * myfunction(void * param1 : itype(_Ptr),
void * param2 : itype(_Ptr)
) : itype(_Ptr);

Currently, the "address of" operation can be performed on these functions without type parameters. This produces a value with generic function types.

e.g.
genericFunctionPointerVariable = &myfunction;

We must be able to supply concrete type parameters along with the address of operations.

e.g.
integerFunctionPointerVariable = &myfunction<int, int>

[dtarditi]

We can express this syntactically now with PR #581. We can take the address of generic functions and generic function instantiations. We still need to test this further.

When we implement type variables with representation information, we need to implement restrictions on taking the addresses of generic function instantiations. For parameter/return types, we have to make sure that the instantiated argument/return types have the same calling convention as the argument/return types using the representation type instead.

For example, suppose we have a functionforany(T).f(T arg that has a type parameter T that uses 4-byte integers as the representation for T. It might be OK to call f<float> because at calls, we can convert floats to the 4-byte integer representation. On some architectures floating point numbers are passed differently than integers. But taking the address of f might not be OK, because we would not know to do the conversion at indirect calls.

[lenary]

I believe we need these (calling convention-related) restrictions on all instantiations though, rather than solely for the address-of operator. The caveat is I have potentially failed to consider a point in the design space, please do correct me if I’m wrong.