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
As pointed out in #1297 (comment), we should discuss our strategy regarding the alloc feature and its priority when creating user API. This should also be documented, once we discussed and agreed on a strategy.
TL;DR: Should we provide interfaces primarily like A, B, or C.
A: fn get_data(&self) -> Result<Vec<T>> which is feature-gated
B: fn get_data(&self, buf: &mut T) -> Result<()>
C: Both where either A or B is prefixed/suffixed, such as _in_buffer or _owned
The text was updated successfully, but these errors were encountered:
So far, the applied approach is unspoken and was never really discussed. "We just did it somehow", mostly. From my point of view, it was a 66.6% prefer non-alloc and a 33.3% do as you like which usually defaults to alloc > non-alloc.
As pointed out in #1297 (comment), we should discuss our strategy regarding the
alloc
feature and its priority when creating user API. This should also be documented, once we discussed and agreed on a strategy.TL;DR: Should we provide interfaces primarily like A, B, or C.
fn get_data(&self) -> Result<Vec<T>>
which is feature-gatedfn get_data(&self, buf: &mut T) -> Result<()>
_in_buffer
or_owned
The text was updated successfully, but these errors were encountered: