I'm not sure of webview's policy on API compatibility, so perhaps a more backwards-compatible approach would be preferable - in that case, a webview_get_binding or similar could be added that returns the bound arg and/or function for a name.

We are trying to preserve maximum backwards compatibility, but I think we can consider changing unbind slightly before releasing v0.11.0, since it has been recently introduced.

I think there is a vague idea that the webview API functions shouldn't return anything in most cases (besides webview_create). It just seems to be a recent convention. This also applies to #735. I'd rather have the ability to return values, but maybe that should be in a more specific function like webview_get_binding or similar ones that provide a peek within webview itself from the outside.

@justjosias In this case, I think it should return the argument. For example, if a programmer mallocs a variable and passes it to bind, then upon unbind, they can conveniently free it. Otherwise, they would need to remember to call another function, free, and then unbind. It seems more natural to unbind and free, to me.

@dandeto I agree. That behavior does seem more intuitive. I'm just thinking about API consistency and backwards compatibility. Do you have any thoughts there?

@justjosias In this case, I think changing from void to void* is backwards-compatible. Before, the user needed to keep track of a mallocd variable some other way, or opt to allow a little memory to leak. Changing the return type won't break that pre-existing code, it just gives the programmer a way to improve it.

Oh, as far as consistency goes, I think the void pattern emerged because most methods aren't really storing anything (except bind in this case) - they are just wrapper functions that cause different behaviors in a webview window.