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.

Sign up for GitHub

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

Jump to bottom

Implement ByteSlice and ByteSliceMut for Vec<u8> #992

Open
joshlf opened this issue Mar 1, 2024 · 0 comments
Open

Implement ByteSlice and ByteSliceMut for Vec<u8> #992

joshlf opened this issue Mar 1, 2024 · 0 comments

Comments

@joshlf
Copy link
Member

joshlf commented Mar 1, 2024

Builds on #1.
@shashitnak shashitnak mentioned this issue Mar 14, 2024
Open
joshlf added a commit that referenced this issue May 8, 2024
@joshlf
[ref] Move Ref definition into its own module
b457b67 
This allows us to more strictly enforce the requirement that, for
`Ref`'s `ByteSlice` field, methods are never called other than those
defined on the `ByteSlice`, `ByteSliceMut`, `IntoByteSlice`, and
`IntoByteSliceMut` traits. We accomplish this by keeping the field
private, and only exposing unsafe getters which return, for example,
`&impl ByteSlice`.

We also introduce new traits - `CopyableByteSlice` and
`CloneableByteSlice`. We tighten the `Copy` and `Clone` impls for `Ref`
to require these bounds. Previously, `ByteSlice` required that its
"dereference stability" requirement applied to any `Copy` or `Clone`
impls, but this would have prevented us from implementing `ByteSlice`
for `Vec`. By splitting the requirement into separate traits, we open
the door to supporting `Vec` (#992).
@joshlf joshlf mentioned this issue May 8, 2024
Merged
joshlf added a commit that referenced this issue May 8, 2024
@joshlf
[ref] Move Ref definition into its own module
41aa8bf 
This allows us to more strictly enforce the requirement that, for
`Ref`'s `ByteSlice` field, methods are never called other than those
defined on the `ByteSlice`, `ByteSliceMut`, `IntoByteSlice`, and
`IntoByteSliceMut` traits. We accomplish this by keeping the field
private, and only exposing unsafe getters which return, for example,
`&impl ByteSlice`.

We also introduce new traits - `CopyableByteSlice` and
`CloneableByteSlice`. We tighten the `Copy` and `Clone` impls for `Ref`
to require these bounds. Previously, `ByteSlice` required that its
"dereference stability" requirement applied to any `Copy` or `Clone`
impls, but this would have prevented us from implementing `ByteSlice`
for `Vec`. By splitting the requirement into separate traits, we open
the door to supporting `Vec` (#992).
joshlf added a commit that referenced this issue May 8, 2024
@joshlf
[ref] Move Ref definition into its own module
3e8f3c4 
This allows us to more strictly enforce the requirement that, for
`Ref`'s `ByteSlice` field, methods are never called other than those
defined on the `ByteSlice`, `ByteSliceMut`, `IntoByteSlice`, and
`IntoByteSliceMut` traits. We accomplish this by keeping the field
private, and only exposing unsafe getters which return, for example,
`&impl ByteSlice`.

We also introduce new traits - `CopyableByteSlice` and
`CloneableByteSlice`. We tighten the `Copy` and `Clone` impls for `Ref`
to require these bounds. Previously, `ByteSlice` required that its
"dereference stability" requirement applied to any `Copy` or `Clone`
impls, but this would have prevented us from implementing `ByteSlice`
for `Vec`. By splitting the requirement into separate traits, we open
the door to supporting `Vec` (#992).
joshlf added a commit that referenced this issue May 8, 2024
@joshlf
[ref] Move Ref definition into its own module
36159b7 
This allows us to more strictly enforce the requirement that, for
`Ref`'s `ByteSlice` field, methods are never called other than those
defined on the `ByteSlice`, `ByteSliceMut`, `IntoByteSlice`, and
`IntoByteSliceMut` traits. We accomplish this by keeping the field
private, and only exposing unsafe getters which return, for example,
`&impl ByteSlice`.

We also introduce new traits - `CopyableByteSlice` and
`CloneableByteSlice`. We tighten the `Copy` and `Clone` impls for `Ref`
to require these bounds. Previously, `ByteSlice` required that its
"dereference stability" requirement applied to any `Copy` or `Clone`
impls, but this would have prevented us from implementing `ByteSlice`
for `Vec`. By splitting the requirement into separate traits, we open
the door to supporting `Vec` (#992).
joshlf added a commit that referenced this issue May 8, 2024
@joshlf
[ref] Move Ref definition into its own module
d7ccc5a 
This allows us to more strictly enforce the requirement that, for
`Ref`'s `ByteSlice` field, methods are never called other than those
defined on the `ByteSlice`, `ByteSliceMut`, `IntoByteSlice`, and
`IntoByteSliceMut` traits. We accomplish this by keeping the field
private, and only exposing unsafe getters which return, for example,
`&impl ByteSlice`.

We also introduce new traits - `CopyableByteSlice` and
`CloneableByteSlice`. We tighten the `Copy` and `Clone` impls for `Ref`
to require these bounds. Previously, `ByteSlice` required that its
"dereference stability" requirement applied to any `Copy` or `Clone`
impls, but this would have prevented us from implementing `ByteSlice`
for `Vec`. By splitting the requirement into separate traits, we open
the door to supporting `Vec` (#992).
joshlf added a commit that referenced this issue May 9, 2024
@joshlf
[ref] Move Ref definition into its own module
475e6e1 
This allows us to more strictly enforce the requirement that, for
`Ref`'s `ByteSlice` field, methods are never called other than those
defined on the `ByteSlice`, `ByteSliceMut`, `IntoByteSlice`, and
`IntoByteSliceMut` traits. We accomplish this by keeping the field
private, and only exposing unsafe getters which return, for example,
`&impl ByteSlice`.

We also introduce new traits - `CopyableByteSlice` and
`CloneableByteSlice`. We tighten the `Copy` and `Clone` impls for `Ref`
to require these bounds. Previously, `ByteSlice` required that its
"dereference stability" requirement applied to any `Copy` or `Clone`
impls, but this would have prevented us from implementing `ByteSlice`
for `Vec`. By splitting the requirement into separate traits, we open
the door to supporting `Vec` (#992).
joshlf added a commit that referenced this issue May 9, 2024
@joshlf
[ref] Move Ref definition into its own module
0461109 
This allows us to more strictly enforce the requirement that, for
`Ref`'s `ByteSlice` field, methods are never called other than those
defined on the `ByteSlice`, `ByteSliceMut`, `IntoByteSlice`, and
`IntoByteSliceMut` traits. We accomplish this by keeping the field
private, and only exposing unsafe getters which return, for example,
`&impl ByteSlice`.

We also introduce new traits - `CopyableByteSlice` and
`CloneableByteSlice`. We tighten the `Copy` and `Clone` impls for `Ref`
to require these bounds. Previously, `ByteSlice` required that its
"dereference stability" requirement applied to any `Copy` or `Clone`
impls, but this would have prevented us from implementing `ByteSlice`
for `Vec`. By splitting the requirement into separate traits, we open
the door to supporting `Vec` (#992).
github-merge-queue bot pushed a commit that referenced this issue May 9, 2024
@joshlf
[ref] Move Ref definition into its own module (#1218)
1e35482 
This allows us to more strictly enforce the requirement that, for
`Ref`'s `ByteSlice` field, methods are never called other than those
defined on the `ByteSlice`, `ByteSliceMut`, `IntoByteSlice`, and
`IntoByteSliceMut` traits. We accomplish this by keeping the field
private, and only exposing unsafe getters which return, for example,
`&impl ByteSlice`.

We also introduce new traits - `CopyableByteSlice` and
`CloneableByteSlice`. We tighten the `Copy` and `Clone` impls for `Ref`
to require these bounds. Previously, `ByteSlice` required that its
"dereference stability" requirement applied to any `Copy` or `Clone`
impls, but this would have prevented us from implementing `ByteSlice`
for `Vec`. By splitting the requirement into separate traits, we open
the door to supporting `Vec` (#992).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@joshlf