-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Funcs should behave as Closures with extra type information. #997
Comments
This would make so, so, happy. :) |
@marcusnaslund |
I'm curious, what is the underlying difference between a |
As far as I am aware, there is no actual difference between the types in the C output. Using Func types assumes a Closure type with a thunk and context Pointer is defined by the SDK and that is about it. Now, Func types are needed to keep type information about the closure and ensure typechecking, since a Closure is simply a pair of Pointers (casting a Func to a Closure means you don't know how to call it anymore). |
In other words, Func types are not actually defined anywhere (as opposed to pretty much every other type in ooc), they behave as (and expect) Closures but are a necessity for typecheking and calling the functions correctly. |
Interesting, thanks. Sounds like an easy fix, then. |
Shouldn't be too difficult, especially making the types compatible. I will be trying to fix #998 today and then I'll be on this one. |
Concretely, you should be able to access Closure fields and methods without having to cast a Func into a Closure.
Func should really just be used to specify the type of the raw function pointer (thunk) stored by the Closure.
In the bundled sdk, this change has two small effects:
In ooc-kean, this helps with cleaning up closures, since you can call
free()
without casting all your Funcs into Closures.All in all, I believe this is the kind of small features that should be acceptable, since it is just a small quality of life improvement regarding two baked-in types that have been known to be a hassle to work together, while they effectively represent the same thing.
The text was updated successfully, but these errors were encountered: