Jason Orendorff

I think using a trait is better. The idea is that the *user* decides what the return type is, and Rustler figures out what to do with it. So a...

I don't know how readable this is, but here's the approach I took for a little Scheme implementation I've been messing around with: https://github.com/jorendorff/cell-gc/commit/149ce249bb4ac565783deeef9bcdbc502d061e5d Before: ```rust fn char_upcase, args: Vec>...

Of course I don't mean to propose any particular detail of that for Rustler. In particular, that `builtins!` macro syntax is silly. 🤡 I just wanted to show that *something...

Cool. I considered something like this for Rustler, but didn't think @hansihe would like the slight extra allocation overhead or the extra runtime overhead of the type check. I couldn't...

Oh, it looks like your code avoids all but a word of allocation overhead. That seems close enough. It's just the runtime check then; and that will be a well-predicted...

Upgrades probably can't be made safe. But we could probably add some kind of `unsafe upgrade: my_upgrade_fn` option to `rustler_export_nifs`. (Requiring the user to type in the `unsafe` keyword is...

Item 4 is very hard to fix. The macros could define the trait, and then there would be no coherence worries. But that seems too silly to contemplate.

We could use `Any`. It would cost a word per resource and a conditional branch per `from_term()`, and I honestly don't really know how the destructor would work. But it...

Yeah, this has hit me more than once, just trying to debug misbehaving tests. Rustler can provide its own `print!` and `println!` macros that work around this.

Rustler has APIs like that too, but they don't do anything to solve this problem. I still think just replacing `print!` and `println!` is the way to go here.