Passing `Proc`s with non-default calling conventions across libs about crystal

[ysbaddaden]

I wondered "how does Rust do it" and they annotate the type declaration (system is stdcall on windows x86):

type PHANDLER_ROUTINE = Option<unsafe extern "system" fn(CtrlType: DWORD) -> BOOL>;
pub unsafe extern "system" fn SetConsoleCtrlHandler(HandlerRoutine: PHANDLER_ROUTINE, Add: BOOL) -> BOOL;

type PEVENT_CALLBACK = Option<unsafe extern "system" fn(pEvent: PEVENT_TRACE)>;
pub unsafe fn EventCallback(&self) -> &PEVENT_CALLBACK;

What's the issue with annotating the type?

[straight-shoota]

To avoid attaching calling conventions to types themselves

Why would you want to avoid that? In the C headers, its also attached to the function type, right? So I figure it would make sense to do the same in Crystal lib definition.
That means if you want to call the same function signature with different calling conventions, you'll need to define separate proc types for that. I don't see how this could be a problem, though.

[HertzDevil]

Maybe we could allow the alias to "carry" a @[CallConvention] annotation that is only meaningful in those lib fun contexts. What I mean is that IMO we should strive to avoid making Callback an entirely different Crystal type from Proc because that would be quite a significant breaking change.

[straight-shoota]

But if alias means more than just a different name, it would also be quite a change.

I think this needs to go on the Proc type itself. This could work based on just an annotation, meaning @[CallingConventionA] Proc(Int) is a different type from Proc(Int).

However, maybe an optional generic type argument would be better suited for that? Proc(Int, calling_convention: CallingConventionA)