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
I found the untrusted crate and thought it was a good idea. I looked through the source code and there's no magic in it, it just encapsulates byte slices so that only APIs that won't be panic can be accessed, and no operations that may panic be done internally. But reading complex structures containing strings or byte strings from &[u8] either cannot avoid extra allocations or will get bunchs of issues about ownership. I'd like to have both benefits of Bytes's exemption from extra allocation, and untrusted's no-panic guarantee.
Similar points seems to be made in #254.
The text was updated successfully, but these errors were encountered:
and no operations that may panic be done internally
Not only at API level, but also including internal operations. Although API can also say "this operation will not be panic", it may be necessary to emphasize that. But anyway it's true that the discussion can be continued in #254.
I found the
untrusted
crate and thought it was a good idea. I looked through the source code and there's no magic in it, it just encapsulates byte slices so that only APIs that won't be panic can be accessed, and no operations that may panic be done internally. But reading complex structures containing strings or byte strings from&[u8]
either cannot avoid extra allocations or will get bunchs of issues about ownership. I'd like to have both benefits ofBytes
's exemption from extra allocation, anduntrusted
's no-panic guarantee.Similar points seems to be made in #254.
The text was updated successfully, but these errors were encountered: