@iliana uh it’d be called toot-rs tho

@catoutofbed

@iliana
Rusts ffi is a bit of a mess if you also want to use the code internally

A lot of unsafe is needed to pass things through c

@catoutofbed I was thinking it would all be rust, with a C layer on top?

@catoutofbed like there would be a conversion into a struct that has a C repr

@iliana
Also i had trouble figuring out field order in rust structs but that's probably deterministic?

@iliana
I mean mostly
You'd have to have wrappers around the functions you would use when calling native rust code
Or else push around raw pointers

@catoutofbed pushing raw pointers seems mildly reasonable tbh

@catoutofbed like. once you leave rust I don't give a fuck what you do, just don't modify my memory

@iliana
Yeah but when in rust
You don't want to deal with raw pointers yeah?
So you'd have to have wrappers functions at the rust-c boundry to convert them from/to raw pointers

@iliana @catoutofbed definitely not, wrappers are the way. possibly generated automatically with a compiler plugin or macros.

@CobaltVelvet @catoutofbed are there existing compiler plugins or macros (ideally macros) for this btw?

@iliana @catoutofbed i don't know of any but haven't needed it either

@CobaltVelvet @catoutofbed anyway. that's probably a far-future goal and having just a nice rust API around the mastodon client interface is still quite a task on its own

@iliana @CobaltVelvet @catoutofbed what sort of C API would you like? If it's GObject-based (hint, hint) I could use some help with gnome-class in Rust to generate bindable APIs 😃

@federicomena I think I want something lighter as the base, but GObject is a totally reasonable target as well

@iliana it's just that with GObject there already are idioms for async APIs and such, already bound to many languages.

E.g. if you are on a Glib main loop, http://antoyo.ml/rust-gnome-hackfest-november can plug Rust callbacks and idioms into the Glib async framework.

@martensitingale @iliana 😊