so am I right in thinking that every rust function with a generic return, e.g. collect(), sum(), into(), is implemented by constraining the return to implement some trait and then just calling that trait?
-
Show this thread
-
Replying to @mountain_ghosts
Pretty much. Or it takes a closure as an argument (which I guess is technically still what you're saying)
1 reply 0 retweets 1 like -
Replying to @sgrif
I may write up how I came to understand this as a blog post
1 reply 0 retweets 1 like -
Replying to @mountain_ghosts
You may find this code mildly interesting as well: https://github.com/diesel-rs/diesel/blob/master/diesel/src/sqlite/connection/raw.rs#L93-L96 … -- only case I've ever needed explicit turbofish for a generic argument and not the return type.
1 reply 0 retweets 1 like -
Replying to @sgrif @mountain_ghosts
What's happening here is that SQLite needs a C function pointer for "body of this custom SQL function" (which takes a `void *` of whatever "context" you want), and then another function pointer to drop that context. 1/
1 reply 0 retweets 0 likes -
Replying to @sgrif @mountain_ghosts
We wanted an API where you just give us a closure with the function body, so our context is just a boxed trait object for that (wrapped in our own closure to handle deserialization of arguments and serialization of return value) 2/
1 reply 0 retweets 0 likes
Actually it's not even a trait object. It's just a generic `Box<T>` -- anyway I found it super neat that you can do this even with `extern "C" fn`s. Just give it the generic type for the actual closure you passed it and you'll get what you need for C interop
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.