Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Evaluate, Discuss + Document role of "alloc" feature in Crate #1303

Open
phip1611 opened this issue Aug 9, 2024 · 1 comment
Open

Evaluate, Discuss + Document role of "alloc" feature in Crate #1303

phip1611 opened this issue Aug 9, 2024 · 1 comment

Comments

@phip1611
Copy link
Contributor

phip1611 commented Aug 9, 2024

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
@phip1611 phip1611 assigned phip1611 and unassigned phip1611 Aug 9, 2024
@phip1611
Copy link
Contributor Author

phip1611 commented Aug 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant