You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current input with zero-copy of the keys is very nice from a performance view, but it requires users to jump through hoops if it's not a 100% direct call (e.g. some of our internal incremental FFI patterns).
Having multiple ways of feeding data (borrowed key, owned key, indexed key?) would be neat in order to make this a bit more ergonomic.
Rabbit holes: How does this work if we also want to support other input types like i32 in the future? (Enum explosion?)
The text was updated successfully, but these errors were encountered:
The current input with zero-copy of the keys is very nice from a performance view, but it requires users to jump through hoops if it's not a 100% direct call (e.g. some of our internal incremental FFI patterns).
Having multiple ways of feeding data (borrowed key, owned key, indexed key?) would be neat in order to make this a bit more ergonomic.
Rabbit holes: How does this work if we also want to support other input types like i32 in the future? (Enum explosion?)
The text was updated successfully, but these errors were encountered: