Base.CFunction is user-visible but undocumented

[stevengj]

#26486 introduced a struct CFunction in Base that is returned by @cfunction for interpolated function arguments:

julia> @cfunction $sin Float64 (Float64,)
Base.CFunction(Ptr{Nothing} @0x0000000116262a90, sin, Ptr{Nothing} @0x0000000000000000, Ptr{Nothing} @0x0000000000000000)

Although this type is user-visible, it is currently undocumented (both in the @cfunction docs and because it lacks a docstring).

CFunction has an unsafe_convert method to Ptr{Cvoid}, so it can be passed as a callback argument. (But CFunction doesn't work with ccall!) But users still need to know about the type — e.g. in PyCall I have to store it in a struct.

(Should this type be exported?)

[vtjnash]

But users still need to know about the type — e.g. in PyCall I have to store it in a struct.
(Should this type be exported?)

I think I should make it a subtype of Ref{Cvoid} – that's typically the expected annotation for most of these ccall-related APIs. Note though that if python provides a void *env-type argument, it's much more efficient to use that argument for its intended purpose (much as you would have done in the past), rather than to ignore the argument and use the dynamic closures (as provided by $ and struct CFunction).

[StefanKarpinski]

Can't we just document the type as it is?