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

Consider adding BytesRef #300

Open
carllerche opened this issue Oct 15, 2019 · 3 comments
Open

Consider adding BytesRef #300

carllerche opened this issue Oct 15, 2019 · 3 comments

Comments

@carllerche
Copy link
Member

carllerche commented Oct 15, 2019

This would be the Bytes equivalent of WakerRef.

If we do that, then we could switch Bytes::slice_ref -> BytesRef::new(&my_bytes, my_slice)... possibly even adding BytesRef::new_unchecked.

Follow up to #298.

@carllerche carllerche added this to the v0.5 milestone Oct 15, 2019
@seanmonstar
Copy link
Member

What does this add over let slice = &bytes[a..b]?

@carllerche
Copy link
Member Author

It lets you slice further into owned handles.

@Matthias247
Copy link
Contributor

Matthias247 commented Dec 9, 2019

When you clone a WakerRef you get a Waker. Which in Wakers cases typically is just a refcount bump, since the Waker has already been allocated.

What would cloneing a BytesRef do? If it gives us Bytes, then the clone in the vtable needs to be implemented as a heap allocation. If it gives us another BytesRef (in order to just slice the ref), then the required vtable function is different.

@carllerche carllerche removed this from the v0.5 milestone Dec 15, 2020
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

3 participants